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Windows 2003 Server 
Expert Workshop (2 nap) 


A Windows 2003 tecbnológiai újdonságainak felfedezése. 


Szakítson időt a Windows 2003 újdonságainak felfedezésére! Nálunk 
két nap alatt megtudhatja mindazt, amit egyedül másfél év alatt lehet 
összeszedni! 


. TÉMAKÖRÖK: 
lAz Active Directory újdonságai 


í 
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i Erdők közötti tranzitív trust; tartományok átnevezése; sémabővítés deaktiválása, felülírása; 
. kezdeti replikáció mentésből (DCPROMOJ; Global Catalog-mentes bejelentkezés; Active 
Directory Application Partition és az Active Directory-integrált DNS újdonságai; Forest és 
Domain Functionality Level, frissítéshez: ADPrep; LDAP-újdonságok: TLS-támogatás, TTL a 
bejegyzéseken, Digest autentikáció, Virtual List View, elmenthető lekérdezések; Active Di- 
rectory Migration Tool, User State Migration Tool; 





A Group Policy újdonságai 


" Resultant Set of Policy; Új házirendcsomagok: NetLogon, Credential Manager, Terminal Ser- 
vices, kliensoldali DNS-beállítások; Software Restriction Policies; Administrative Templates 
Web View; A GPO korlátozása WMI-szűréssel; Group Policy Management Console: GPO 
mentés-visszaállítás, export-import 


Fejlesztői újdonságok rendszergazdáknak 


Hasznos programocskák készítése (Visual) Notepad segítségével: .NET Framework; 
ASP.NET; ADO.NET 


LEN KRA AA TE KTEL EA e 


GUID Partition Table; Headless Server; Automated System Recovery; Volume Shadow Copy; 
új WMI Providerek: a replikációhoz, a trust-kapcsolatokhoz, DFS-hez, nyomtatókezeléshez; 
Parancssori WMI (WMIC.EXE) 


CAPA G NEE LTE KAEE ET 

EFS: több felhasználó, titkosítás WebDAV-megosztáson 

Certificate Services újdonságok: auto-enrollment felhasználók számára is, Certificate Map- 
ping, módosítható tanúsítványsablonok, delta CRL-támogatás, központi kulcstárolás, kulcs- 
visszaállítás 

Software Update Services 


(MSG EZ ÉN e 





http.sys és Web Administration Service; Worker Process Isolation Mode; Web Garden 
Demand Start; URL Authorization; XML Metabase; POP3 és SMTP szolgáltatás 


2003 április 10-11. 
2003 május 15-16. 
2003 június 12-13. 
Jelentkezés: www.netacademia.net/workshop/VWV2003 


Időpontok: 


Köszöntő 


Generációváltás 


A Microsofttól megszokott hosszas vajúdás után (Whistler 
3.NET Server 3 Windows Server 2003) megérkezni látszik 
a Windows operációs rendszer következő verziója. Mivel 
immár publikusan letölthető próbaváltozat is rendelkezésre 
áll, úgy döntöttünk, ,átállunk". Ez azt jelenti, hogy mostan- 
tól mind a tech.net magazinban, mind tanfolyamainkon a 
Windows Server 2003 lesz az alap operációs rendszer — már 
ha a körülmények megengedik. 

Tiltó körülmény például az Exchange 2000 jelenléte, mely 
olyan erősen támaszkodik a Windows 2000-ben lévő IIS-re 
és AD-re, hogy az új oprendszer-változat nem is jó neki. 

Ha abból indulunk ki, hogy a következő Windowshoz 
nem kell újból letenni az összes MCP-vizsgát, azt hihet- 
nénk, hogy nincs is benne semmilyen újdonság. De van. A 
[w2003RevGuidel címről letölthető, több mint száz oldalas 
Reviewer"s Guide semmi mást nem tartalmaz, mint az újdon- 
ságok táblázatos felsorolását. Miközben átrágtam magam a 
dokumentumon, folyamatosan jegyzeteltem, mi mindennel 
kell majd foglalkoznunk a közeljövőben. Két A4-es oldalt tett 
ki az újdonságok felsorolása — címszavakban! Példaként áll- 
jon itt az Active Directory-újdonságok köre (ezek azok, ami- 
ken van mit kipróbálni): 

A Erdők közötti tranzitív trust; tartományok átnevezése; 
sémabővítés deaktiválása, felülírása; kezdeti repliká- 
ció mentésből (DCPROMO); Global Catalog-mentes 
bejelentkezés; Active Directory Application Partition; 
Forest és Domain Functionality Level; LDAP-újdon- 
ságok: TLS-támogatás, TTL a bejegyzéseken, Digest 
autentikáció, Virtual List View, elmenthető lekérdezé- 
sek; Active Directory Migration Tool, User State Mig- 
ration Tool. 


A teljesen újraírt IIS6 egészen új fogalomtárat vezet be, van 
itt WAS szolgáltatás és webkert (webgarden), http.sys és XML 
alapú metabase. Méretes listáim vannak a Group Policy, a 
biztonság, a hálózatkezelés, a parancssori lehetőségek új- 
donságairól, az integrált .NET-keretrendszerről stb. 


Jelen számunkban részletes elemzést olvashatnak a tartomá- 
nyok és tartományvezérlők átnevezéséről (nem triviális!), né- 
hány Group Policy-újdonságról (folyt. köv.), a WMI parancs- 
sori kezeléséről (WMIC.EXE azoknak, akik nem óhajtják fej- 
ből tudni a WMI-osztályokat), valamint az EFS új funkcióiról. 
Most pedig jöjjön egy kis önreklám: 


Windows Server 2003 Expert Workshop! 


Felhívom a tisztelt Olvasóközönség figyelmét, hogy a kéz- 
zelfogható ismeretek, tapasztalatok elsajátítása érdekében 
létrehoztunk egy kétnapos Workshopot (lásd a szemközti ol- 
dalon) a Windows Server 2003 újdonságainak gyakorlatban 
történő kipróbálására, gondolván azokra a szerencsésekre, 
akik nem várhatják meg, amíg lapunk hónapok hosszú során 
át lehozza az összes tudnivalót, hanem minél hamarabb át 
szeretnének térni az új rendszerre. 


Fóti Marcell 

marcellfonetacademia.net 

A szerző a NetAcademia vezető oktatója 
MCSE, MCT, MCDBA, MZ/X 


http://technet.netacademia.net/go?kulcsszo 
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Windows Server 1003 


Tartományok átnevezése 


talom 


Windows 2000 esetében igen körültekintően kellett eljárni az Active Directory tartomá- 
nyok nevének megválasztásánál: az ugyanis a későbbiekben nem volt megváltoztatható. 
A Windows Server 2003 megjelenésével lehetővé vált a névcsere, bár körültekintésre 

















meet most is szükség van, mert a névcsere egyben a tartományi fa átalakításának is eszköze. Ebben a cikkben végigvesszük a tar- 
tományátnevezés lépéseit, s bónuszként felvillantom az application partitionok kezelésének lehetőségeit is. 
jú ányá és lépéseit, s bó ként felvill pplication partitionok kezelésének lehetőségeit i 
a 
7 ATETEKEEZEZ 4. oldal 
a E Ela Aton Ven Window Heh gásóts g 
z lmi] - 
sz szemen Csoportos házirendek a Mindorus server 2003-ban 
né LES Bemutatkozik a Group Policy Management Console 
E Szi ösáttáse A Windows 2000 bevezetésével elkezdett csoportházirendek vonalán is erősít a Microsoft a 
DÉR sssétá Windows 2003 megjelenésével. A Windows 2000-ben még újdonságnak számító csoportos há- 
ke zirendek kezelését teszi könnyebbé a Windows 2003 környékén megjelenő Group Policy Ma- 
c ealintása nagement Console (GPMC), vagy a Resultant Set of Policy (RSoP). 
áj rs 
a 
DE avar g. oldal 
Era wes 
MRP 


Titkosított fájlrendszer v2.D ESSSSS 


Az Encrypting Filesystem a Windows XP-ben és 
a Windows Server 2003-ban 


Meet TEEKEz 3 
EEC — ee ksotan 


A titkosított fájlrendszer a Windows 2000-ben jelent meg. Az EFS akkori verziója még több 
szempontból is gyerekcipőben járt, de azóta eltelt három év és a ,gyermek" fát Szosz ká S THETÁSÉN EGG ÉKE Fat 


Tegye kat Ha e Eeen TAT. 


szépen cseperedett. Cikkünkben bemutatjuk, mit , tud" az EFS a Windows XP-ben, illetve a 
Windows Server 2003 tartományi környezetben. 











Rendszerfelügyelet parancssorból 
A Windows 2003 Server WMI szolgáltatásai 


A WMI (Windows Management Instrumentation) rendszerfelügyeleti felületet 1996- 
ban, akkor még WBEM (Web Bases Enterprise Management) néven kezdte el kidol- 
gozni a Microsoft, a Compag, a BMC, a Cisco és az Intel. A cél egy univerzális, kü- 
lönféle hardver- és szoftverelemekhez egyaránt használható felület létrehozása volt. A 
z —— Microsoft most még rátett egy lapáttal: a Windows 2003 Serverben egy nem is akár- 
milyen parancssori eszközt is kaptunk hozzá. 








Hoturotalus - 03 


15. oldal 


A Microsoft Exchange 2000 útválasztása 
Az üzenetek útja egy szervezeten belül és kívül 


Egy szervezetben már két Exchange kiszolgáló esetén is felmerül a kérdés: merre 
mennek az elküldött üzenetek? Gyakran nem is tudja a rendszergazda, 

mi történik tulajdonképpen több kiszolgáló esetén. 

A cikkben szó lesz az üzenetek útjáról, az útválasztásról, és az összefüggésekről. 


al. oldal 


E WGéttdiag 44 ütt gt § EGT. EG: tecnnet 





Eltemetett bitek: szteganográfia 


Avagy nem minden arany, ami fénylik? 

x. ellentétben a kriptográfiával, ahol a támadó észreveheti az üzenetet és mó- 
dosíthatja azt, a szteganográfia célja, hogy a nyílt szöveget úgy rejtse el a gya- 
númentes üzenetbe, hogy a támadó ne is láthassa meg, hogy a továbbított üzenet egy 
második üzenetet tartalmaz." 


95. oldal 





Portál Paraldigma)] 


Avagy mit tegyünk, ha sürgősen portált kell építenünk? 


Ha főnökeink vagy ügyfeleink azt várják tőlünk, hogy integráljunk egy-két tucat külön- 
böző alkalmazást úgy, hogy az információk és szolgáltatások az Interneten is elérhetők 
legyenek, mindezt egyszerű legyen kezelni, és persze az egész minimális költségvetésből 
és tegnapra kell, akkor bizony nehéz dolgunk van. Az ma már nem kérdés, hogy ilyenkor 
vállalati portált kell építeni, de hogy milyen eszközökkel, milyen architektúrával és mi- 
lyen platformon, az már nem olyan egyértelmű. Jön a portál para. 


30. oldal 





A? Active Directory programozott elérése 


Sokszor esett már szó az Active Directory eléréséről, bűvöléséről, most azonban a saját kódból 
történő elérést szeretném bemutatni, illetve illusztrálni néhány példán keresztül. Úgy gondo- 
lom, ezek az ismeretek mind fontosak lehetnek egy AD-integrált alkalmazás fejlesztésekor. 


35. oldal 





Formális módszerek az informatikában [7] 
A Petri-hálók további alkalmazásai 


A sorozat első részeként áttekintettünk néhány alapfogalmat az informatikában 
használatos formális módszerekkel kapcsolatban, majd áttértünk a Petri-hálók- 
ra. A topológia bemutatása után most mélyebb részleteket szeretnék bemutatni. 


39. oldal 


Internet Exlporer javítás 


Az Internet Exploreren két újabb biztonsági rést javíthatunk a 2003. február 
AN ASPSESSIONIDOAGAGBNKZCIOMFOADOMJGIKILDCCNNKIE [elején megjelent MSO3-004-es számú hotfixszel. Mint már megszokhattuk, 
ez a javítás tartalmazza az Explorerhez eddig kiadott javításokat, így ha va- 
laki eddig elmulasztotta volna betömködni a már ismert réseket, az egyszer- 
re megteheti az Insdownload] helyről letölthető biztonsági javítással. 


43. oldal 


Microsoft Internet Explorer 





A bitlegelők tragédiája 

Egyszer volt, hol nem volt, volt egyszer sok tehénpásztor. Az egyik arra gondolt, hogy több te- 
hén többet tejel, ezért megnövelte a csordája létszámát. Kiderült, hogy igaza lett, mire a szom- 
széd pásztor is hasonlóképp tett. Egy bolond százat csinál, de még a felénél sem tartottak, ami- 
kor annyi tehén bőgött a réteken, hogy már egyikük sem lakott jól teljesen... 


44. oldal 
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- Tartományok átnevezése / Windows 


VUindows Server 2003 


74 Mindorws server c003 


Tartományok átnevezése 


Windows 2000 esetében igen körültekintően kellett eljárni az Active Directory tartományok nevének 
megválasztásánál: az ugyanis a későbbiekben nem volt megváltoztatható. A Windows Server 2003 
megjelenésével lehetővé vált a névcsere, bár körültekintésre most is szükség van, mert a névcsere egy- 
ben a tartományi fa átalakításának is eszköze. Ebben a cikkben végigvesszük a tartományátnevezés lé- 
péseit, s bónuszként felvillantom az application partitionok kezelésének lehetőségeit is. 


Tekintsük meg az alábbi, átnevezés előtt álló tartományt, mely- 
nek VETEMENYES.HU a neve, s a veteményesben egy UBOR- 
KA nevű tartományvezérlő csücsül (Control Panel System 
ikon). 


EHEZ SNS] 
Advanced l Automatic Updates — ] Remote 
General Computer Name ] Hardware 


Windows uses the following information to identify your computer 
on the network. 


Computer description: [ 
For example: "1IS Production Server" or 
"Accounting Server". 
Full computer name: 
Domain: 





To rename this computer or join a domain, click Change. Change... I 


E Uborka a veteményesben... 


Az a feladatunk, hogy a tartomány neve KISKERT.HU-ra változ- 
zon. A fenti ábrán látható, csábító feliratú , Change..." nyomó- 
gomb sajnos nem alkalmas a tartomány nevének megváltoz- 
tatására, helyette a telepítő CD-n, a ValueaddsftMgmtv 
Domren könyvtárban található RenDom.EXE-t kell használni. 


A RenDom.EXE ugyan ezernyi kapcsolóval rendelkezik, de van 
közöttük egy veszélytelennek tűnő változat, a /list, így neki- 
esünk a feladatnak, hátha azonnal sikerül... Parancssort ide! 


HIZTTES 





5 A tartomány átnevezésének első kísérlete 


Hát ez nem sikerült. Valami hiányzik. De mi? 


Funkcionalitási szintek 


A Windows 2000-nél bevezetett Mixed és Native üzemmódok 
a Windows 2003-nál is megtalálhatók, csak a fogalom neve 
más: Functional Levelnek hívják, és külön állítható tartományi, 
valamint erdőszinten. A termék súgója remek összefoglaló táb- 
lázatot tartalmaz arról, hogy az egyes új AD-funkciók milyen 
FuncLevel meglétét igénylik. 


A tartományok nevének megváltoztatásához erdőszintű 2003 
FuncLevel szükséges, ami egyenlő azzal, hogy az erdő min- 
den fájának, s abban minden tartomány minden DC-jének 
2003-as Active Directoryt kell futtatnia, ráadásul 2003-as 
FuncLevelen. 

Ez azt jelenti, hogy a névváltoztatáshoz sajnos nem elég egyet- 
len DC-t átállítani 2003-ra, ezt mindegyikkel meg kell tenni, 
majd a FuncLevelt minden tartományon, végül magán az er- 
dőn is fel kell emelni 2003-as magasságba. 

Vigyázat! A FuncLevel csak feljebb tornászható, visszaút 
nincs! 

A funkcionalitási szint megtekintésére és átállítására az Active 
Directory Domains and Trusts szolgál, mégpedig úgy, hogy ha 
a tartomány nevén jobbkattintunk, tartományszintű, míg ha az 
MMC-konzol gyökerén, az erdőszintű beállításhoz jutunk, 
amint azt az alábbi montázs mutatja: 


5 : Active Directory Domains and Trusts 


File Action Wiew Help 














E A tartományi és erdőszintű funkcionalitási szint 
átállítása 


Először a tartományi funkcionalitási szintet kell megemelni, 
mert amíg létezik Mixed (NT4-et tartalmazó) vagy natív (W2K-t 
is befogadó) tartomány, addig az erdőszint átállítása sikertelen. 
A következő ábráról nemcsak az olvasható le, hogy milyen 
szintek léteznek, mire lehet áttérni, hanem az is, hogy a Win- 
dows 2003 AD alapértelmezésben hogyan települ: Mixed, 
vagyis NT4-kompatibilis üzemmódban. Annak ellenére ez tör- 
ténik, hogy egy különálló, friss telepítés esetén elhanyagolható 
annak esélye, hogy valaki NT4 Backup Domain Controllert 
szeretne telepíteni a tartományba. De lám, lehet. 





ete 4e : MV z technet 


3 
Domain name: 
vetemenyes.hu 
Current domain functional levet 
Windows 2000 mixed 


Select an available domain functional levek 


[Windows 2000 native r] 
mee Servet 2003 ei 
on domain functional Teve 


els, cick Help." 





EEG [/ ESSHEGE] 
E A tartomány funkcionalitási szintjét emeljük 2003-ra! 


A funkcionalitási szint felemelését az összes tartományon el 
kell végeznünk, mivel a cél az erdőszintű FuncLevel felemelé- 
se! Miután az összes tartománnyal végeztünk, s a replikáció is 
lezajlott, erdőszinten is áttérhetünk 2003-ra: 


Raise Forest Functional Level El 12 


Forest name: 
vetemenyes.hu 


Current forest functional levet 
Windows 2000 


Select an available forest functional levet. 





AV After you raise the forest functional level, it cannot be reversed. For more information on 
forest functional level, cck Help. 


Lksse] crea [/ Her ] 


E Az egész erdő funkcionalitási szintjének megemelése 


Itt már csak 2000 és 2003 szintek léteznek, értelemszerűen 
nincs NT4-es erdőszint, mert abban a történelmi korban még 
nem léteztek erdők. 


Az átnevezés további feltételei 

1. Az új tartománynév nyilván új DNS-zónába fog tartozni, 
ezt az átnevezés előtt célszerű megcsinálni, és dinamiku- 
san frissíthetővé tenni. 

2. Fontos átnevezési feltétel, hogy ha az erdőben Exchange 
2000 van, sajnos le kell tennünk az átnevezésről. Nem 
megy. 

3. Tartomány átnevezésére az Enterprise Admins csoport tag- 
jai képesek. 

4. Az átnevezés során a DC-k újraindulnak, míg a Ren- 
Dom.EXE-nek futnia kell, mert ő koordinálja az átnevezés 
menetét. Ebből az következik, hogy ne valamelyik DC-n, 
hanem például egy munkaállomáson futtassuk. (Ha csak 
egy DC-nk van, tehát nincs szinkronizálási igény, akár 
azon a DC-n is futtathatjuk.) 


A RenDom.EXE 


És most lássuk a , varázslót", az eszközt, amivel az átnevezési 
műveletet el kell végeznünk. Használata első pillantásra szo- 
katlan, ugyanis mintegy ötször-hatszor le kell futtatnunk (mind- 
annyiszor más kapcsolóval) ahhoz, hogy elvégezze nem is 
egyszerű feladatát. 


ach.net ú4árkd a w i 


Az eljárás menete egyébként a következő: a RenDom ) 


egy XML-fájlba exportálja a címtár átnevezhető név- 
tereit. Ezt a fájlt valamilyen szerkesztőprogrammal 
(pl. Notepad) átirkáljuk, majd visszaimportáljuk az 
AD-be, ahol az replikálásra kerül. Ezután vezényszó- 

ra az összes DC nekilát a saját címtárpéldányában (NTDS.DIT) 
elvégezni az átnevezést, s ha végzett, az új néven újraindul. 
A szokásos kapcsolókat (felhasználói kontextus-váltás, egy 
adott géphez csatlakozás, output fájl nevének beállítása stb.) 
nem részletezve az alábbi lényeges funkciói vannak a Ren- 
Dom.EXE-nek (a felsorolás sorrendje egyben a használat sor- 
rendje is!): 





/list Ez a lépés kiexportálja a címtárból az átnevezhe- 
tő névterek listáját a domainlist.xml nevű fájlba. 
(Ezt kell majd a rendszergazdának módosítania.) A 
parancs a Domain Naming Master FSMO-szerep 
hordozójához fordul. Ha ezt a gépet nem lehet el- 
érni, baj van! 
/showforest Az átszerkesztett domainlist.xml alapján megjele- 
níti a jövőbeni AD-struktúrát. Így még az előtt le 
lehet ellenőrizni módosításaink helyességét, hogy 
belekezdenénk a műveletbe. Ha valami nem stim- 
mel, ismét módosítsuk a fájlt! 
A módosított domainlist.xml visszaimportálása a 
címtárba (msDS-UpdateScript attribútum). Ebben a 
lépésben születik a dclist.xml fájl is, amely ilyenkor 
minden DC-ről ezt tartalmazza: cStateclnitial 
dStatez (lásd később). 
Emellett ez a lépés elkészíti a DNS-zónába fel- 
veendő új rekordok listáját is, megpróbálja 
beregisztrálni az új SRV rekordokat, illetve 
dnsrecords.txt néven lementi az indítási könyvtár- 
ba is. Az erdőben bizonyos funkciók letiltódnak. 
Annak ellenőrzésére szolgál, hogy az összes mó- 
dosítandó DC felkészült-e az egyidejű átnevezés- 
re. Futtatásakor módosul az előző lépésben létre- 
jött delist.xml fájl, amiből kiolvasható a DC-k álla- 
pota. Addig nem szabad továbblépni, amíg az 
összes DC cStatesPreparedc/States állapotba 
nem kerül! 
Ha minden DC felkészült az átnevezésre, most 
vezényszóra bele is kezdenek a feladatba, majd 
újraindulnak! Vigyázat! Az újraindulás leállítha- 
tatlan! Csak akkor indítsuk el ezt a lépést, ha nem 
okoz zavart a DC-k újraindulása! A folyamat vé- 
gén a dclist.xml ezt tartalmazza: 
cStatexzDoned/Statez 
/end Sikeres átnevezés után ez a lépés visszaállítja az 
AD-t normális üzembe, vagyis megszünteti a 
/upload lépés által okozott korlátozásokat. 
Ha újabb átnevezésre van szükség, előbb ezzel a 
paranccsal ki kell pucolni a msDS-UpdateScript 
attribútumot. 








/upload 





/prepare 





/execute 








/elean 





Talán ezzel sokakat sikerült egyszer s mindenkorra elijeszte- 
nem az átnevezéstől, pedig a lépések egyáltalán nem bonyo- 
lultak, s maga az XML-fájl is pici, aranyos. 


Az első lépés 

Elsőként tehát a /list kapcsolóval futtatjuk a RenDom.EXE-t, így 
a jelenlegi tartományneveket tartalmazó XML-fájlhoz jutunk, 
amit majd megfelelően át kell javítanunk. 
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Windows Server 2003 





"RenDom /list 


Az alábbi ábrán azt a domainlist.xml fájlt láthatjuk, 
ami a veteményeskertünkről készült (könnyű nekem, 
csak egy DC-m van): 





c?xml version-"1.0" ?2 
cForest: 
- aDomainz 
21-- PartitionType:Application --5 
egere es DGNSlKOKSzates vetette yes HiZONSNAT Ő 
azZDNSnameszDomainDNSsZones.vetemenyes.huc/ONSnamez 
aNetBiosName /5 
aDcName /5 
c/Domainz 
- eDomains 
€!-- PartitionType:Application  --5 
a2Guid:48eebd84-1951-4f4c-872d-a6a2Z8f 188f49-/Guid- 
zDNSnamezForestDnszZones.vetemenyes. huc/oNsnamez 
cNetBiosName /5 
SDcName /: 
c/Domain:z 
- cDomains 
£1-- ForestRoot --5 
a2Guidodő8ce0af-b11a-4481-93b6-d4925f45315bc/Guid: 
nameszvetemenyes.huc/öNSnamez 
I aNetBiosNamez VETEMENYESc/NetBiosNamez 
cDcName /5 
£/Domain: 
jc/Forests 








E Az átnevezéshez használt, a RenDom által generált 
domainlist.xml 


Bekereteztem azokat a részeket, ahol névcserére kerülhet sor. 
Két (a DNS Server által használt) application partition után kö- 
vetkezik a tartománynév. Itt jegyzem meg, hogy a tartomány 
kétféle nevét (DNS és NetBIOS) egymástól függetlenül meg le- 
het változtatni, hisz ez a két név akár eltérő is lehet. További 
fontos megjegyzés, hogy a DNS-név átírása általában egyenér- 
tékű a tartományi hierarchia megváltoztatásával is. Ha tehát a 
vetemenyes.hu helyett ezt írom: kiskert.hu, ezzel a tartományt 
teljesen áthelyezem a ,hu" hierarchiában. 

Bár a tartományátnevezés dokumentációja (rendomdocl] vilá- 
gosan leírja, hogy minden, azonos névtérbe eső nevet egyszer- 
re kell megváltoztatni (tehát az application partitionokét is), 
ezen valahogy átsiklott a tekintetem, így én csak magát a tarto- 
mányt neveztem át, aminek hatására ,zombi" AppPartitionok 
maradtak a címtárban. Az eset tanulságos volta miatt azonban 
így haladunk tovább, mert így meg tudom mutatni, hogy kell 
,zombikat gyilkolni". 

A [rendomdoc] tanulmányozása egyébként is kötelező, mert 
mintegy ezer olyan mikrokörülményre hívja fel a figyelmet, 
amit egy ilyen cikkbe lehetetlen belegyömöszölni: mit te- 
gyünk, ha SmartCard logonnal súlyosbított a helyzet, mik a le- 
hetséges hibajelenségek, hogyan kell a GPO-linkeket az átne- 
vezés után frissíteni stb. 

Most ezeket a finomságokat hagyjuk, gondolatban írjuk át a 
fenti XML-fájlban a vastagon jelzett tartományneveket VETE- 
MENYES-ről KISKERT-re. 





A módosítások ellenőrzése 


Mielőtt továbbmennénk — különösen összetett tartományfák 
esetén — érdemes leellenőrizni a változtatásokat. A 





2. RenDom /showforest. EZT z 
segítségével , grafikus" formában meg tudjuk tekinteni, mivé is 
alakulna az erdő, ha ezzel az XML-fájllal tovább dolgoznánk: 








E A módosítások utáni AD-erdő , grafikus" megjelenítése 


Ha a struktúra megegyezik azzal, ami a módosításunk célja, jö- 
het a következő lépés, az XML-fájl visszatöltése az AD-ba. 


Vigyázz, kész... 


TEREKDONEÜSTOZAA TT TET MKETETZETTETFITMETETTT] 





Mindössze ennyit kell tennünk, és a módosítások (maga az 
XML fájl!) bekerülnek az msDS-UpdateScript attribútumba 
(Configuration naming context, Partitions konténer). 
Nagyon fontos tudnivaló, hogy amerre az msDS-UpdateScript 
attribútum szétreplikálódik, a tartományi erdő zárolás alá ke- 
rül. Amíg véget nem ér az átnevezés, nem lehet: 

A új DC-t telepíteni, 

HA új tartományt beilleszteni az erdőbe, 

A trust-kapcsolatokat készíteni! 


Ezek a korlátozások majd a /end kapcsolóval szüntethetők 
meg, nyilván a teljes folyamat sikeres lezárulása után. 

A parancs futtatására válaszként ismét egy XML-fájlt 
(dclist.xml) kapunk, ebben találjuk leírva, hogy melyik DC hol 
tart az átnevezési folyamatban: 


c?xml version-"1.0" ?2 
- eDCLists 
cHash:5OGUgzaOdoiNddYPyLaViopcU ts-c/Hash: 
cSignaturesyOBKIxm t ImOV4zvőrKFdIINDt6E- c/Signatures ) 
- SDC5 
aNamesuborka.vetemenyes.huc/Namez 


aPasswordoSfwPznrMp4w- c/Passwords 
ALastError50€/LastError5 
cLastErrorMsg /5 
cFatalErrorMsg /2 
cRetry /5 
£/DC5 
€/DcLists 


ED A kocka el van vetve, az átnevezés elindult! 
(dclist.xml) 


Most egy adag várakozás következik, hisz meg kell várnunk, 
amíg: 
A elkészülnek az új SRV-rekordok a DNS-ben (amelyek 
egyébként a régi hostrekordokra mutatnak!!!) 
HA az msDS-UpdateScript attribútum szétreplikálódik az 
erdőben 


Miért van az, hogy az új SRV-rekordok a régi hostnevekre fog- 
nak mutatni? Kinek kell ez a kavarás? A munkaállomásoknak! 
Az átnevezés során a tartomány összes gépének DNS-neve 
(FODN) magától átáll majd az új névre, azaz a hostrekord át- 
költözik az új zónába — kivéve a tartományvezérlőket! 

Éppen ezért a korábbi DNS-zóna (vetemenyes.hu) törlését nem 
szabad megtenni addig, amíg a DC-k teljes DNS-nevét egy két- 
lépéses folyamat során (NetDom.EXE) kézzel át nem állítgat- 
juk! 

Ez azért van így, hogy ne legyen olyan pillanat, amikor a DC- 
k megtalálhatatlanok, ,elugranak" a munkaállomások elől. A 
tartományvezérlők FODN-jének megváltoztatását lásd később. 





A felkészülés ellenőrzése 
Futtassuk a 


4. RenDom /prepare —— 


parancsot, ami frissíti az előbb mutatott dclist.xml fájlt. Addig 
kell várnunk, amíg az összes DC cStatexPreparedc/State: ál- 
lapotba kerül. 

Esetleg próbálkozhatunk azzal, hogy az Active Directory Sites 
and Services segítségével felgyorsítjuk a replikációt, minden- 
esetre idővel minden DC felkészülten várja a nagy pillanatot. 
Ha ez mégsem következik be, az átnevezési folyamatot meg- 
szakíthatjuk a /end kapcsolóval. 

A mi esetünkben minden (mind az egy ;) DC felkészült állapot- 
ba került. 


. rajt! 


5. RenDom /execute 


Emlékeztetőül: ez a lépés az összes érintett DC-n megszakítha- 
tatlan újraindulást fog okozni, csodálkoztam is nagyon, amikor 
legelőször csináltam! 

Tulajdonképpen itt van jelentősége annak, hogy ne a DC-k va- 
lamelyikén futtassuk a programocskát, mert ha a gép újraboo- 
tol alatta, bajosan fogja tudni frissíteni a dclist.xml fájlt, pedig 
ez alapján tudjuk eldönteni, mindenütt sikeres volt-e az átne- 
vezés. Ha végül cStatexzDoned/States állapotba kerülnek, ak- 
kor jó. Ha cStatesErrorc/States lesz a vége, forduljunk biza- 
lommal a Microsoft Tudásbázishoz. 


A folyamat befejezése 


Végül szabadítsuk meg az Active Directoryt láncaitól, hogy is- 
mét minden funkció (új DC, új tartomány, új trust) elvégezhe- 
tő legyen az erdőben: 


6. RenDom /end 


A parancs hatására kipucolódik az msDS-UpdateScript attribú- 
tum, s ennek elterjedésével fokozatosan felszabadul az AD-erdő. 
Ezután következik a munka dandárja (a teljes teendőlistát lásd 
a [rendomdoc]-ban)! 
I munkaállomások és tagkiszolgálók kétszeri(!) újraindí- 
tása 
HA új számítógéptanúsítványok kérése 
TA a Start Menü ikonjainak kijavítása a DC-ken (például 
elromlik a Domain Security Policy) 
A régi DNS-zónafájlok törlése (ezzel még várjunk!!!) 
ma stb. 


Group Policy linkek kijavítása (GPFixUp) 


A csoportos házirend olyan objektum, melynek fele az AD-ban 
található (jogosultságlisták, a GPO neve stb.), fele pedig fájlok- 
ban (templatek stb.). Ezek kölcsönösen hivatkoznak egymásra, 
s minden megy, mint a karikacsapás mindaddig, amíg a hivat- 
kozások élnek. Az AD-ból fájlba mutogatás nem romlik el a 
tartomány átnevezésének következtében, mert GUID-nevű 
könyvtárakra mutogatunk, s a GUID nem változik. 

A visszirányú mutogatás azonban elromlik, a GPO-fájlok 
ugyanis LDAP-nevekkel mutogatnak vissza a címtárra. Az át- 
nevezés után tehát az összes policyfájlon végig kell futni, és a 
benne lévő tartományhivatkozásokat ki kell javítani. 

Ezt a RenDom.EXE mellett található GPFIXUP programocská- 
val kell elvégezni: 


hn.net tt tdag w i 





A paraméterezés szerintem önmagáért beszél. A /dc kapcsoló- 
val — a GPO-szerkesztés ősi szabályainak értelmében — a PDC 
Emulatorra mutassunk! Ott szépen kijavulnak a házirendfájlok, 
s a File Replication Service segítségével eljutnak a többi tarto- 
mányvezérlőre is. 


A tartományvezérlők átnevezése 


Mint azt a bevezetőben, valamint a szemközti hasábban kifej- 
tettem, a DC-k teljes domainneve (FODN) nem áll át az új név- 
re. Ezt a lépést nekünk kell megtennünk a NetDom.EXE segít- 
ségével, aki régi cimboránk: már az NT4 Resource Kitnek is ré- 
sze volt (ma pedig a telepítőlemezen csücsül a SupportNTools 
könyvtárban). Akkoriban FODN-átirkálásra még nem lehetett 
használni, de az összes korabeli tartományfunkcióra igen: 
munkaállomás csatlakoztatására, trust létrehozására stb. 

Az új változat lesz alkalmas az FOND átállítására, mégpedig 
oly módon, hogy lehetővé teszi, hogy egy adott gépnek egy 
időben két FODN-je legyen! Ez tehát a titok nyitja, így bizto- 
san nem fogunk elveszíteni egyetlen munkaállomást sem! 

Ha már FODN-csere, egy nagy lélegzettel az UBORKA nevet 
is kicserélhetjük CUKKINI-re, így: 





E További FODN felvétele a gépre 


Mint az látható, egyértelműen azt a válasz kapjuk, hogy új 
gépnév added, vagyis valahol a réginek is meg kellett marad- 
nia. Meg is maradt. Ha most a /enumerate kapcsolóval kilistáz- 
zuk tartományvezérlőnk jelenlegi neveit, ezt kapjuk: 


E Csoda Piripócson: két FODN egy gépen! 


Két lépés van már csak hátra: a két FODN sorrendjének felcse- 
rélése (ami újraindítást kíván): 








Valamint (reboot, és az új hostrekord meglétének ellenőrzése 
után) a korábbi név eltávolítása: 





Megfigyelhető, hogy ebben a legutóbbi parancsban már az új 
gépnévre kellett hivatkoznom a csatlakozáskor! 


Újbóli átnevezés előtt... 
Ha valaki ezek után notórius tartomány-átnevezővé válik, rész- 


vétem, de ehhez a mániához még tudnia kell azt is, hogy újabb 
tartományátnevezés előtt le kell futtatni a 
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parancsot! 
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- Tartományok átnevezése / Windows 


Uindows Server 2003 


Röviden" ennyi. Az elnagyolt részeket csak a Win- 
dows Server 2003 Expert Workshop tanfolyamon 
mutatjuk be, mert azok esetében (is) sokkal többet ér 
a gyakorlat, mint a sok leírt betű. 


BONUS: Application Partitionok kezelése 


, Szerencsésnek" mondhatom magam, mert a művelet során el- 
követtem egy óriási baklövést, nevezetesen a DNS által hasz- 
nált application partitionöket nem neveztettem át (emlékez- 
zünk: domainlist.xml fálj szerkesztése). Mivel azonban a DNS 
névtér is megváltozott, a DNS Server kiköltözött az általa ad- 
dig használt partíciókból, amelyek üresen álltak a címtárban — 
hátha beleköltözik valaki. 

Erről NTDSUTIL segítségével győződtem meg, az alábbiak sze- 
rint (és ez egyben az application partitionok kezelésének híva- 
talos módja is): 





parancsot. Ezzel belépünk a tartománykezelési ágba, ahol a 
műveletek megkezdése előtt meg kell határoznunk, melyik 
DC-vel, és milyen kontextusban kívánunk dolgozni. Ezért be- 
megyünk a 


TEEEY EEZTSE jösz ZR 
connection ii 
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almenübe, ahol megadhatjuk a kezelni kívánt DC nevét 





connect to server CUKKINI —— 


innen egyet feljebb kell lépnünk, hogy ismét a domain mana- 
gement szintjén legyünk, tehát 








Ha ez a sok hókuszpókusz mind megvolt, a 


list 


paranccsal kilistázhatjuk az Active Directoryban megtalálható 
névtereket: 





IE Az AD által kezelt névterek (Naming Context) 


Itt látható a Configuration, a Default (DC-kiskert, DC-hu), a sé- 
ma, valamint a 2003-ban már felhasználói alkalmazás által is 
létrehozható application partitionök. Az ábráról jól leolvasha- 
tó, hogy két-két DomainDnsZones és ForestDnsZones is léte- 
zik, ezek közük a vetemenyes.hu nevűek egyszerűen feleslege- 
sek. Nem is maradtak volna meg, ha a domainlist.xml fájlt 
minden szükséges ponton módosítottam volna az átnevezés 
során, de sajnos előbb járt a kezem, mint az eszem, így ottma- 
radtak. Most mit tehetünk? 


Egyrészt örök időkig otthagyhatjuk, mert nem sok vizet zavar- 
nak, másrészt ki is törölhetjük őket — mert nem sok vizet zavar- 
nak. Lássuk a törlést. Figyelem! Active Directory Application 
Partition-törlés következik! Halk dobpergést kérek! 


delete nc VLayonainunszones, VLevetenenyez . UL any] 
TT he partition haz heen nark ű 





E Naming Context törlése az AD-ból 


Hát ez sikerült. Az utasítást megismételhetjük a ForestDnsZo- 
nes névtérre is, az is el fog tűnni. 

Ennél azonban fontosabb, hogy olyan helyen állunk az 
NTDSUTIL-ban, ahonnan új application partitionok létrehozá- 
sára nyílik lehetőség! Készítsünk egy PARADICSOM nevű al- 
kalmazáspartíciót! 


ETETETT TTL TT 


15 systemFlags: OxÖCO00000 - ( FLAG DISALLOW DELETE 
Calrérastruzture DC eparadcsom 0C-k FLAG. DOMAIN. DISALLOW. RENAME / FLAG DOMAIN. DISALLOW. Mt 
No children 15 objectCategory: 


No chááren 1 isCriticalgystemObject: TRUE; 
lalíTOS Guotas DC eparadcsom DC ater 
No chágen IzNTDS Ouotas, DCsparadicsom,i 





E Új alkalmazáspartíció készítése 


Hogy ez mire jó? Erről már egy programozót kellene megkér- 
dezni. 


Fóti Marcell 

marcellfönetacademia.net 

A szerző a NetAcademia vezető oktatója 
MCSE, MCT, MCDBA, MZ/X 


Tartományátnevezést jó pénzért vállalok! 





Kapcsolódó tanfolyamaink: 








Lsoportos házirendek 
a Vindows server 2003-ban. ( 


Bemutatkozik a Group Policy Management 


Console 


A Windows 2000 bevezetésével elkezdett csoportházirendek vonalán is erősít a Microsoft a Windows 
2003 megjelenésével. A Windows 2000-ben még újdonságnak számító csoportos házirendek kezelé- 
sét teszi könnyebbé a Windows 2003 környékén megjelenő Group Policy Management Console 


(GPMC), vagy a Resultant Set of Policy (RSoP). 


Újdonságok az ügyfélmenedzsment területén 


A Windows 2003-ban számos újdonságot illetve még több fi- 
nomítást találhatunk az ügyfélmenedzsment területén; eddig 
nem megoldott, vagy hiányzó funkciók kerültek a Windows 
Server 2003-ba. Íme néhány közülük: 

HI A csoportos házirendek újdonságai közül az egyik leg- 
látványosabb a Group Policy Management Console 
(GPMC), amely jelentősen megkönnyíti a házirendek 
mindennapi kezelését, a hibaelhárítást. 

HA A Resultant Set of Policy segítségével előre láthatjuk a 
házirendek hatásait, és utólag az összes beállítást tud- 
juk ellenőrizni. 

HI WMI szűrők segítségével egyedi módon lehet meghatá- 
rozni a házirendek hatáskörét. 

H Az adminisztratív sablonokban számos újdonsággal ta- 
lálkozhatunk, így például a terminálkiszolgálók, a fel- 
használói profilok, a DNS vagy az alkalmazás-kompa- 
tibilitás beállításait is szabályozhatjuk a házirendből. 

H Végre igazán lehet majd korlátozni a felhasználókat a 
Software Restriction Policy segítségével: milyen alkal- 
mazásokat futtathatnak és melyeket nem? Nehéz lesz 
kibúvót találniuk, ha például a futtatható állományból 
képzett HASH alapján szabályozzuk a futtatható alkal- 
mazások körét! 

HA Egyre több parancssoros program segíti a rendszergaz- 
dák munkáját. A Microsoft arra törekedett, hogy helyből 
lehessen használni őket, de a biztonság kedvéért a sú- 
gót is megerősítették. A parancssori eszközöket távoli 
menedzsmentre is használhatjuk (/S kapcsolóval.) 

HA WMIC is a rendszergazdák munkáját hivatott segíteni, 
egyszerűbbé téve a scritpek futtatását. Erről az eszköz- 
ről külön cikk szól jelen lapszámunkban. 

HI A RIS-t is javítgatták, megújították Redmondban. Ezen- 
túl a kiszolgálótermékeket is lehet majd RIS-sel telepí- 
teni. (Eddig is lehetett egy részüket, de a megoldás ké- 
zi beavatkozást igényelt). Ezen kívül a RIS kliens telepí- 
tővarázslóját — vagyis a CIW képernyőket — is lehet au- 
tomatizálni, így még kevesebb beavatkozás szükséges 
a telepítések elindításához. 


A sok újdonság közül először a Group Policy Management 
Console-t szeretnénk bemutatni. Íme: 





Group Policy Management Console (GPMC) 


A rengetegben az egyik leglátványosabb újdonság a GPMC. 
Egy újabb Management Console modul, amely egy átfogó 
program házirendet használó rendszergazdák számára. Átlát- 
hatóságot biztosít a házirendek háza táján, eddig megoldhatat- 
lannak tűnő, vagy csak keservesen megoldható feladatok el- 
végzéséhez is használható. 


Telepítése 
A cikkírás idején a GPMC Beta 2 állapotban van, a végleges 
verzió várhatóan a Windows 2003 megjelenésekor lesz el- 
érhető. 
A Beta 2 a következő környezetekben telepíthető: 

A Windows Server 2003 vagy 

HA Windows XP SP1T -4- Microsoft .NET Framework -- OFE 

0326469 javítócsomag 


Jelenleg a windowsbeta.microsoft.com lapról tölthető le, 
gpmc.msi telepítőcsomagként. A telepítés roppant egyszerű, az 
MSI csomag futtatásának végeredményeként a GPMC a NProg- 
ram Filesigpmc könyvtárba költözik. MMC modulként érhető 
el, és az Administrative Tools menüben is megjelenik, Group 
Policy Management néven. 

Ha Windows 2003 kiszolgálón telepítjük, mellékhatásként a 
telepítés után már csak ezzel az eszközzel tudjuk a házirende- 
ket állítgatni. Ilyenkor a Windows 2000-nél megszokott he- 
lyen, például az Active Directory Users and Computersben egy 
konténeren a Group Policy lapra kattintunk, már csak az aláb- 
bi üzenet vár: 


MIEZEZTTTTENT TTI 
General [/Managed By ]/ Object ] Security [/COM: Group Policy ] 
You have installed the Group Policy Management snap-in, so this tab is no 
longer used. 


To open Group Policy Management, click Open. s 
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A Group Policy Management Console telepítése után 
a rendszergazda már nem nagyon használhatja az 
addigi házirendkezelési eszközöket az adott számító- 
gépről. De nem kell megijedni, nem csak a Windows 
2003-as, hanem a Windows 2000-es házirendeket is 
kezeli a Management Console, igaz, az első esetben több min- 
denre használható. De ne szaladjuk ennyire előre, előbb is- 
merkedjünk a felülettel! 
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E Az első indítás utáni kép egy Windows 2003 kiszol- 
gálón 


A képen a falatrax.net erdő csoportos házirend menedzsment- 
je látható. A Domains konténer alatt — értelemszerűen — az er- 
dőt alkotó tartományok találhatók. Elárulom: ebben az esetben 
egyetlen tartományból áll az erdő. Egyébként a rendszergazda 
szabályozhatja, mely tartományok látszódjanak a konzolból. A 
Domains feliraton állva a gyorsmenüből (jobbkatt az egérrel) 
Show Domains paranccsal lehet felvenni a tartományokat a 
konzolba. Felhívnám a figyelmet, hogy több tartomány esetén 
ebből a konzolból magát a tartományhierarchiát nem láthat- 
juk, a tartományok függetlenül kezelhetők. Ez abból adódik, 
hogy a csoportos házirendek valódi alapja, egysége egy tarto- 
mány. A házirendek eddig és ezután sem öröklődnek tartomá- 
nyok közt. 

A Sites konténerben az erőhöz tartozó telephelyeket láthatjuk. 
Szintén a rendszergazda határozza meg, mely telephelyeket 
szeretné látni a konzolban, és melyeket nem. A megjelení- 
tés/elrejtés módszere is hasonló, a Sites konténeren állva jobb 
klikk Show Sites paranccsal lehet kiválasztani a megjeleníten- 
dő telephelyeket. Ha kibontjuk a telephelyeket, láthatjuk a 
hozzájuk kötött házirendeket. 


Megjegyzem, a gyorsmenüt minden konténeren állva érdemes 
végignézni. Többek közt gyorsmenüből lehet indítani más me- 
nedzsment eszközöket is, például az Active Directory Sites and 
Servicest vagy az Active Directory Users and Computerst. 
Még mindig a második ábránál maradva — Windows 2003-as 
Active Directory esetén — látható két funkció, amiről most rö- 
viden írok csupán. 

Az egyik a Group Policy Modelling — ami megfelel a Windows 
2003-ban megjelenő új funkciónak, a Resultant Set of Policy 
tervezőmódjának (RSoP planning mode). Segítségével előre 
láthatjuk, milyen hatásai lesznek a tervezett házirendbeállítá- 
soknak. 

A másik a Group Policy Results — ami megfelel a Resultant Set 
of Policy naplózómódjának (RSoP logging mode). Ezzel konk- 
rét számítógép-felhasználó párosra vonatkozóan tudjuk meg- 
nézni az éppen érvényben levő házirendek pontos beállításait, 
azaz a végeredményt. 





Nem mintha eddig nem lehetett volna kideríteni a pontos vég- 
eredményt (a Windows 2000 Resource Kit gpresult és gpotool 
programok segítségével), de az RSoP lerövidítheti a hibakere- 
sés idejét, használata könnyebb, grafikus felülete van, és (ter- 
vezőmódban) előre is láthatunk vele, bár ez csak Windows XP- 
vel és Windows 2003-mal működik. Úgy gondolom, ez a té- 
makör külön megér egy cikket, ezért itt most nem mennék be- 
le további részletekbe, maradjunk a Group Policy Manage- 
ment Console-nál. 


Tartományvezérlők és a GPMC 


Talán emlékszik a kedves olvasó, hogy Windows 2000 Active 
Directory esetén a csoportos házirendeket alapértelmezésben 
arról a tartományvezérlőről nyithatja meg a rendszergazda, 
amelyik a PDC-emulátori funkciókat látja el. Nos az alapértel- 
mezés most sem változott. A GPMC is a tartomány(ok) PDC- 
emulátorához fordul. De csakúgy, mint korábban, most is átál- 











ete done aug [de 
Current domain controller: 
"w2003s.falatraz.net 
Look im this domain: 


[[docsznet -] 
Change to: 
c 
C Any available domain controller 
C Any available .NET domain controller 
€ This domain controller: 
Domain controllers 


Ww2003s falalrax net Iroda 





lítható, mely tartományvezérlőhöz csatlakozzon a konzol. 

A tartományvezérlő kiválasztása a tartomány nevén állva a 
gyors menüből Change Domain Controller paranccsal történ- 
het. Több telephelyes környezetben mindenképp érdemes sza- 
bályozni, hova is fordul a konzol, hisz a PDC-emulátor lehet 
egészen messze is. 


Több erdő kezelése egy konzolból 


Nem csak egy tartomány házirendjeit lehet elérni a konzolról, 
hanem az Active Directory erdőben (forest) levő valamennyit. 
Sőt! A képen ugyan nem látszik, de több erdő csoportos házi- 
rendjét is képes a rendszergazda egyetlen felületről a GPMC 
segítségével kézben tartani! Vegyesen lehet használni Win- 
dows 2000 és Windows 2003 erdők házirendjeinek kezelésé- 
re! (Ahhoz, hogy más erdők házirendjei is elérhetők legyenek 
csupán egy kétirányú trustot szükséges kiépíteni a két erdő kö- 
zé a Beta 2 állapotban. A végleges programban várhatóan elég 
lesz egyirányú megbízott kapcsolat a működéshez, ezt majd a 
rendszergazda szabályozhatja.) 

Ha valaki már most arra vágyik, hogy a Windows 2003-as kör- 
nyezetéből menedzselje a Windows 2000 Active Directoryt, és 
mindehhez nem szeretne kétirányú trustot, a regisztrációs 
adatbázisban kis változtatás után már a Beta 2-es állapotú 


techn 
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GPMC-t is használhatja. Mindehhez a következő registrymó- 
dosítást kell végrehajtani: 





A beállítások érvényre juttatásához registrymódosítás után a 
GPMC-t újra kell indítani. A végleges verzióban az ígéretek 
szerint a felhasználói felületről lehet majd beállítani ezt a funk- 
ciót. 


Egy tartomány kezelése 


Szűkítsük a kört és nézzük, mit találunk egy tartomány kerete- 
in belül a konzolban! 

Bal oldalon látható az összes olyan konténer, amelyhez házi- 
rendet tudunk rendelni, valamint azoknak a házirendeknek a 
listája, amelyek közvetlen a tartományhoz tartoznak. 





E Az ablak BAL oldala 


Egy konténeren állva a jobb oldalon rögtön megjelennek az 
adott helyhez közvetlenül kötött (linkelt) házirendek. 





Ahogy a képen is látszik, a Domain Controllers konténerhez 
egyetlen házirend kötődik közvetlenül, az alapértelmezett De- 
fault Domain Controller Policy. 


Házirendek öröklődése 


Ezen a lapon láthatjuk az adott konténerre ható összes háziren- 
det, beleértve azokat is, amelyeket örökölt egy konténer a hie- 
rarchia felette levő részeiből. Vigyázat! Ebben az ablakban 
nem láthatóak a telephelyekhez kötött házirendek! 


h.net téeTrtrdgy 





altalanos Talatrax net Enabled 


E A Domain Controllers konténerre ható összes házirend 


A Group Policy Inheritance fülön tipikusan olyan beállítások- 
kal találkozunk, amelyek a házirendek öröklődésével kapcso- 
latosak és befolyásolják a házirendek hatását. Rögtön az első — 
Precedence feliratú — oszlopban látható például a hatályos há- 
zirendek prioritási sorrendje. De látható az is, hogy mely házi- 
rendet honnan örökölte a konténer (Location oszlop). 

A hatáskört befolyásolja, ha egy konténeren megakadályozzuk a 
házirendek öröklődését (Block Inheritance), illetve ennek ellen- 
téte az Enforcement (eddig No Override néven találkoztunk ve- 
le), amely továbbra is erősebb a Block Inheritance beállításnál. 
Még mindig ugyanazon a konténeren, de jobb oldalt a Delegati- 
on lapon állva láthatjuk a jogosultságokat az adott konténerhez. 





E A Domain Controllers konténer Delegation lapja. 


Ha bal oldalon kiválasztunk egy házirendet, akkor a jobb olda- 
lon annak a részletei láthatóak. Az alábbi képen a jobb oldal 
látható. 
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" Bemutatkozik a Group Policy Management Console / Windows 


Csoportos házirendek a Windows Server 2003-ban 


E 


Látható rögtön, hogy kire érvényes a házirend. 
Ugyanezen a lapon alul állíthatók a WMI szűrők, 
amik egyedi tulajdonságok alapján teszik lehetővé a 
hatásterület pontosabb meghatározását. Erről később 
részletes is lesz szó. 


A Details fülön — ami az alábbi képen is látható — kaphatunk 
információt a házirendről, például leolvashatjuk a házirend 
GUID-ját, vagy azt, hogy felhasználókra, számítógépekre vagy 
mindkettőre tartalmaz beállításokat, vagy esetleg le van tiltva. 





B Egy házirendről kapható információk és beállítások 


A Settings fülön — ami az alábbi képen is látható — részletesen 
megnézhető a házirend összes beállítása érthető, könnyen 
emészthető formában. 








3 HTML alapú riport a TS házirendről 


A fenti Settings fülre kattintva tulajdonképp egy HTML riport 
jön létre az adott házirendről. Bárki, akinek olvasási joga van 
az adott házirendhez, képes ilyen riportot létrehozni. Koráb- 


ban, ha egy felhasználónak vagy rendszergazdának nem volt 
olvasási és írási joga egy házirendhez, meg sem tudta nyitni a 
Group Policy Editorral. 

A GPMC-vel innen már csak egy lépés, és HTML vagy XML 
fájlba exportálhatjuk az összes beállítást, jelentősen meg- 
könnyítve ezzel a dokumentálást. Az exportált fájlban nem- 
csak a beállítások, de a Scope, Details és a Delegation fülek 
tartalma is szerepel. 


Az adminisztratív sablonok és a GPMC 


A riport létrehozásához a GPMC az adminisztratív sablonokból 
veszi a megjelenített neveket. Ha — mondjuk — magyar nyelvű 
riportot szeretnénk, használjunk magyar sablonokat hozzá! 
Meghatározható, honnan vegye fel a sablonokat a GPMC a ri- 
portkészítéshez. 

A GPMC a következő sorrendben jár el. 


1. Megnézi, a következő registry kulcs értékét: 


Ha ez ki van töltve, innen veszi a sablonokat. Érdemes tehát 

beállítani. 

2. Ha a registry kulcs értéke nincs szabályozva, körülnéz a 
9owindir9oVnf könyvtárban, ha ott talál bármit, az alapján 
készíti a riportot. 

3. Ha az előbbi két helyen nem jár sikerrel, a házirend 
SYSVOL alatt levő könyvtárából olvassa be a sablonokat. 





A GPMC nem nézi végig az összes helyet: ha az egyikben már 
talált sablonokat, azokat használja. Alapértelmezésben példá- 
ul a registry kulcs nincs szabályozva, viszont a Yowindir9oNinf 
könyvtárban talál sablonokat, akkor annak segítségével képzi a 
riportot, a 3. helyet már meg sem nézi. Jön a kérdés, mi törté- 
nik akkor, ha nem a házirendhez tartozó sablonok alapján ké- 
szül a riport? Ebben az esetben minden beállítás, amihez a sab- 
lonokban nem talál magyarázatot, extra beállításként jeleníti 
meg. A riportban közvetlenül a registry kulcs és értéke jelenik 
meg. Érdemes tehát odafigyelni honnan is szedi a GPMC a sab- 
lonokat, mert könnyen furcsa riportokat kaphatunk. 


Folytatjuk... 


Dorner Csilla 
dorner.csillanetacademia.net 


Kapcsolódó tanfolyamaink: 


tech.net 


Titkosított fájlrendszer ud.0 


Az Encrypting Filesystem a Windows — 
XP-ben és a Windows Server 2003-ban — 


A titkosított fájlrendszer a Windows 2000-ben jelent meg, mint új, üdvözlendő módszer adataink biz- 
tonságos tárolására. Az EFS akkori verziója még több szempontból is gyerekcipőben járt, de azóta el- 
telt három év és a ,gyermek" szépen cseperedett. Cikkünkben bemutatjuk, mit ,tud" az EFS a Win- 
dows XP-ben, illetve a Windows Server 2003 tartományi környezetben. 


Algoritmusok 


Az EFS titkosító algoritmusa a Windows 2000-ben kötelezően 
a DESX volt. A Windows XP SP1 (!) és a Windows Server 2003 
(mostantól egyszerűen csak , W2K3") megjelenésével azonban 
ennek helyébe az amerikai kormányzati körökben DES-t fel- 
váltó új titkosítási algoritmus, az AES (Advanced Encryption 
Standard, ,gyermekkori" nevén Rijndael) lép. Bár az AES kü- 
lönböző hosszúságú kulcsokkal képes üzemelni, a Windows 
minden esetben 256 bites kulcsokat használ a titkosításhoz. 
Az AES mellett használható algoritmusként megjelent még a 
3DES is, de az alapértelmezés minden esetben az AES marad. 
Nagyon fontos, hogy a Windows 2000 csak a DESX algorit- 
must ismeri, ezért az AES (sőt, akár a 3DES) algoritmussal tit- 
kosított fájlokat a Windows 2000 nem képes helyreállítani. 


ki 


[ott nes titok 


Zjtitok - Notepad 


File Edit Format Help 
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B Ez nem sikerült: így néz ki egy AES-sel titkosított fájl, 
miután a Windows 2000 DESX-ként dekódolta 


Az XP SP1 és a W2K3 képes dekódolni a DESX, 3DES és per- 
sze az AES algoritmusokkal is. A Windows XP SP1 nélkül a 
3DES-t még felismeri. A titkosításnál viszont már bonyolultabb 
a helyzet: míg az XP hajlandó a DESX algoritmusig lealacso- 
nyodni, a W2K3 legfeljebb a 3DES-ig ,butítható". Ennek két 
módja van; egyrészt az AES használata helyett a W2K3 tarto- 
mányban előírhatjuk a 3DES használatát (ez azonban nem 
csak az EFS-re, hanem az IPSec-re is hatással lesz). Ehhez egy 
házirendben (különálló gépen érdemes erre a Local Security 
Policyt, tartományi tagok esetén a Default Domain Policyt 
használni) keressük meg és engedélyezzük a következő beál- 
lítást: Local Policies Security Options System cryptog- 
raphy: Use FIPS compliant algorithms for encryption, hashing, 
and signing. 








net ETETETT v i 


Ha csak az EFS titkosítóalgoritmusát szeretnénk meghatározni, 
a registry-be kell belenyúlnunk és létrehoznunk az alábbi ér- 
téket: 








Értékei pedig az alábbiak lehetnek (REG DWORD): 
A 0x6610: AES 
I 0x6603: 3DES 
HA 0x6604: DESX (ez az érték W2K3-ban nem érvényes) 


Alapértelmezett Data Recovery Agent 


A Data Recovery Agent (DRA) tanúsítványa arra való, hogy a 
felhasználó által titkosított fájlokat egy arra kijelölt személy 
(maga a DRA) akkor is ki tudja nyitni, ha a felhasználó kulcsa 
valamilyen oknál fogva nem érhető el. Ennek feltétele, hogy a 
fájl titkosításakor a titkosító kulcsot a felhasználón kívül a 
DRA-(-K) kulcsával is tároljuk. Ez a biztonsági eljárás a Win- 
dows 2000-ben nem kerülhető meg: az EFS ott addig nem volt 
hajlandó titkosítani, míg nem volt legalább egy DRA a rend- 
szerben. Az alapértelmezett DRA az újonnan telepített, nem 
tartományi tag Windows 2000-ken a helyi, tartományban pe- 
dig a tartományi rendszergazda volt; a (File Recovery típusú) 
DRA tanúsítvány a számítógép illetve a tartomány telepítésekor 
automatikusan létre is jött a rendszergazda profiljában. 

Ez a gyakorlat a Windows XP-ben megszűnt, és már az alapér- 
telmezett DRA tanúsítványokat sem hozza létre az operációs 
rendszer. Erre azért volt szükség, mert az automatikusan kelet- 
kezett, rendszergazdai profilban megbúvó helyreállító tanúsít- 
ványok biztonsági problémát jelentettek az ellopott noteboo- 
kok és egyéb módon megszerzett számítógépek esetén (Win- 
dows 2000-ben első dolgunk legyen a helyreállító tanúsítványt 
privát kulcsostul flopira exportálni, majd a privát kulcsot töröl- 
ni a rendszerből!). Szükség esetén a lemez a páncélszekrény 
mélyéről előkaparható, importálható, viszont addig is a fájlja- 
inkat valamelyest biztonságban tudhatjuk. 

Ne felejtsük el, hogy az XP nemcsak a tanúsítványok létreho- 
zásától tekint el, hanem zokszó nélkül titkosít fájlokat akkor is, 
ha nincs elérhető DRA a közelben. Ha egy így titkosított fájl tu- 
lajdonosának privát kulcsa elveszik, a fájl tartalmára keresztet 
vethet. 
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E Nem egy életbiztosítás: Windows XP-ben nincs alapér- 
telmezett Recovery Agent! 


A helyreállító ügynök tanúsítványát tartományi környezetben a 
Default Domain Policy biztonsági beállításai között határoz- 
hatjuk meg: 





















E (9 Restricted Groups 
E (0 System Services 
Ez CA Registry 

E (9 File System 

3. Wireless Network (IEEE 802.11) Pc 


E Az alapértelmezett helyreállító ügynök tanúsítványa az 
alapértelmezett tartományi házirendben 


Ehhez persze arra van szükség, hogy a helyreállító ügynök 
(magyarán a rendszergazda) rendelkezzen File Recovery típu- 
sú tanúsítvánnyal. Ezt kérheti-kaphatja a vállalati CA-tól (ha 
van), vagy generálhatja magának. Hasonló a helyzet a nem tar- 
tományi tag Windows XP-k esetén: mielőtt DRA-t hoznánk lét- 
re, a rendszergazda számára generálnunk kell egy file recovery 
típusú tanúsítványt. Ehhez a cipher parancsot használhatjuk: 


A parancs generál (de nem telepít!) egy File Recovery típusú, 
ún. ,önaláírt" tanúsítványt az aktuális felhasználó nevében-ne- 
vére. Ezt a tanúsítványt a privát kulcs nélkül elmenti az álta- 
lunk megadott nevű, .cer kiterjesztésű fájlba. A privát kulcsot is 
tartalmazó tanúsítvány pedig az azonos nevű .píx fájlba kerül. 
Ezután még két lépés van hátra: 


A A tanúsítványt privát kulcsostul telepítenünk kell a fel- 
használó tanúsítványtárába (ehhez kattintsunk kettőt a 
.pfXx fájlra és menjünk végig a tanúsítványimportáló va- 
rázslón) 


A A publikus kulcsot tartalmazó tanúsítványt pedig be 
kell állítanunk, mint alapértelmezett DRA tanúsítványt. 


Ezt tartományi környezetben az előbb már látott Default Do- 
main Policy-ben, helyi gépen pedig a Local Security Settings 
megfelelő helyén tehetjük meg. 















File Action View Help 


£5/EBISERIÉ 





Status 
[áj There is no policy defined. 







3 CA Account Polides 
F C9 Local Polides 





7 (I Public Key Polices 
AA Enagypting File System fp 
a CI Software Restriction Policies AII Tasks 8 
7 28) IP Security Polices on Local Computer fRelresh 
Export List... 


E Helyreállító ügynök ,, telepítése" különálló Windows 
XP-ben 


Az ,Add Data Recovery Agent..." parancs kiválasztása után a 
varázslóval keressük meg a cipher által generált .cer fájlt, és 
importáljuk a házirendbe. 


Az EFS, a smart card és egyéb biztonsági eszközök 


Az EFS csak a beépített Microsoft Base, Strong illetve Enhanced 
Cryptographic Service Provider (CSP) modulokat képes és haj- 
landó használni. Ez azt is jelenti, hogy az EFS jelen pillanatban 
nem működik együtt semmilyen külső biztonsági eszközzel, 
legyen az smart card, biztonsági USB token, vagy bármi más 
olyan bővítmény, ami saját CSP-t (, biztonsági eszközmeghaj- 
tót") használ. 


Fájlok titkosítása a kiszolgálókon — Windows megosztáson 
keresztül 


A fájlok titkosításához a felhasználó publikus, míg dekódolá- 
sukhoz privát kulcsára van szükség. A Windows megosztott 
mappákban titkosított fájlokat maga a kiszolgáló titkosítja ki-be 
(ez azt is jelenti, hogy a titkosított fájlok a hálózaton , titkosítat- 
lanul" közlekednek). Azonban még maga a titkosítás sem egy- 
szerű, hiszen a fájl kezeléséhez a kiszolgálónak szüksége van 
a felhasználó privát kulcsára. Az pedig a felhasználó profiljá- 
ban található, ezért a kiszolgálónak a profilt meg kell szerez- 
nie. Ennek három módja van: 


mA a felhasználó vándorló (roaming) profilt használ, vagy: 

AA a felhasználó már belépett az adott kiszolgálóra és lé- 
tezik a profilja 

A a felhasználó még nem lépett be az adott kiszolgálóra, 
ezért a kiszolgáló létrehoz (!) számára egy , üres" profilt. 


Ha a profil megvan, és található benne megfelelő tanúsítvány 
(és privát kulcs), a kiszolgáló azt használja, ha azonban nincs 
ilyen, akkor (a W2K3-nak) megint két lehetősége van: 


A Ha van elérhető vállalati tanúsítványkiadó szervezet 
(CA), online a felhasználó nevében kér egy megfelelő 
tanúsítványt (!!!) és tárolja azt a felhasználó profiljában 

A Ha nincs elérhető CA (vagy a kiszolgáló nem W2K3), 
generál egy önaláírt tanúsítványt, és ugyancsak tárolja 
a felhasználó profiljában. 








TETTEKET ETET 2]: 
User profiles store settings for your desktop and other 

82 information related to your user account. You can create a 
different profile on each computer you use, or you can select a 
roaming profile that is the same on every computer you use, 


Profiles stored on this computer: 






Name 
FALATRAXZOOS Administrator 1,74MB Local Local 
FALATRAXZOOSÍ teszt 517KB Local Local 20... 





E Bár a tesztfelhasználó soha nem , járt" a kiszolgálón, 
az első titkosítás alkalmával EFS létrehozta az ő kis 
,Miniprofilját" 


A titkosítás ezután a ,hagyományos" módon megy végbe. A 
fenti lépések azonban különleges biztonsági beállításokat igé- 
nyelnek: 


HA a kiszolgálónak meg kell engednünk, hogy más fel- 
használó nevében eljárhasson; 

A a felhasználó beállításai között nem lehet letiltva a le- 
hetőség, hogy a nevében eljárjanak. 


Mindkét opciót természetesen az Active Directoryban találjuk 
meg, az előbbit az adott számítógép tulajdonságlapjának első 
oldalán, , Trust Computer for delegation" néven — ezt az EFS 
vskiszolgálók" számára engedélyeznünk kell (ez tartományve- 
zérlőknél alapértelmezésben be van kapcsolva). A másik beál- 
lítást pedig a felhasználó tulajdonságlapjának , Account" olda- 
lán, az Account options listában találjuk. 





T Do not reguire Kerberos preauthentication - 


E Ha a kijelölt opció a felhasználónál be van állítva, a tá- 
voli EFS nem fog működni 


Az EFS használatához az , Account is sensitive and cannot be 
delegated" beállítást ki kell kapcsolni. A felette látható , Acco- 
unt is trusted for delegation" opciót viszont az EFS-hez nem 
kell bekapcsolni. 

Ha ezek a feltételek fennállnak, a távoli EFS titkosításnak már 
nincs akadálya. Arra figyeljünk azonban, hogy — hacsak a fel- 
használónk nem vándorló profilt használ — a kiszolgáló által 
generált kulcspár csak a kiszolgálón található profiljában lesz 
megtalálható (tehát szükség esetén onnan kell exportálni is). 


Egy titkosított fájl, több felhasználó 


A Windows XP újdonsága volt, hogy egy titkosított fájlhoz több 
felhasználót is hozzárendelhettünk. Miután a titkosításhoz 
mindössze a felhasználó nyilvános kulcsára van szükség (az 
pedig megtalálható a közzétett tanúsítványokban), ehhez nem 
kell az ,új" felhasználó közvetlen közreműködése. Elég, ha a 
tanúsítványához és publikus kulcsához hozzáférünk; erre vi- 
szont tökéletes hely az Active Directory; ide ugyanis minden, 
a vállalati CA által kiadott tanúsítvány automatikusan bekerül, 
és ,kézzel" is importálhatunk újabb tanúsítványokat. Az új fel- 
használók felvétele tehát valóban nem több mint néhány kat- 
tintás. 








ha 
acnnet S TE TR w i 


Encryption Details for Z:lteszt.txt 


Users Who Can Transparenily Access This File: 
— Certificate Thumbprint 
Administratorládministratorfalatrax2003.hu). F240 0896 3CO9 B7A6 120F 920C E 
! Teszt Elekítesztgfalatrax2003.hu) 8695 6407 BC32 0428 930C 15EF 3 
! 
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Remove 


Data Recovery Agents For This File As Defined By Recovery Policy: 


Certificate Thumbprint 
Administrator[ádministrator€falatrax2003.hu)  805F D356 F28C 46E9 0E65 FB6G5 9/ 





E A fájl titkosításához felhasznált tanúsítványok, és a tar- 
talomhoz hozzáférni képes felhasználók listája 


Ugyanebben a dialógusablakban végre tisztán látható, hogy 
pontosan kinek és pontosan melyik tanúsítványát használta a 
rendszer a titkosításhoz. A tanúsítvány az , ujjlenyomat" (Certi- 
ficate Thumbprint) segítségével könnyen azonosítható. 


Fájltitkosítás webes megosztáson keresztül 


Az ,új" EFS még egy újdonságot tartalmaz, mégpedig a Web- 
DAV megosztáson keresztüli titkosítást. Ennek több előnye is 
van a hagyományos fájlmegosztáson keresztüli titkosítással 
szemben: 


A A titkosítást nem a kiszolgáló, hanem minden esetben 
az ügyfél számítógépe végzi, így megszűnik a profil és 
kulcsmenedzsment problémája 

HA A fentiek értelmében a titkosított fájlok tartalma már a 
hálózaton is titkosítva , utazik" (!) 

A A WebDAV kommunikáció nem más, mint kibővített 
HTTP, így sokkal ,tűzfalbarátabb", mint a ,hagyomá- 
nyos" Windows hálózati forgalom 


A módszert azonban lapzártáig nem sikerült működésre bírni 
(ez a béta szoftverek egyik érdekes sajátossága), ezért erre a té- 
mára egy későbbi számunkban (például az új IIS-t bemutató 
cikkek során) még visszatérünk. 


Fülöp Miklós 
mickCnetacademia.net 


solódó tanfolyamaink: 
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Ez 


€) 


kendszerfelügyelet 
parancssorból 


A Windows 2003 Server WMI szolgáltatásai 


A WMI (Windows Management Instrumentation) rendszerfelügyeleti felületet 1996-ban, akkor még 
WBEM (Web Bases Enterprise Management) néven kezdte el kidolgozni a Microsoft, a Compag, a 
BMC, a Cisco és az Intel. A cél egy univerzális, különféle hardver- és szoftverelemekhez egyaránt hasz- 
nálható felület létrehozása volt. A Microsoft most még rátett egy lapáttal: a Windows 2003 Serverben 
egy nem is akármilyen parancssori eszközt is kaptunk hozzá. 


A WMI történelme a Windowsban 


A Windows Management Instrumentation névre átkeresztelt 
technológia a Windows NT 4.0 Service Pack 4 CD-n jelent 
meg , élesben" először — leginkább csak, mint programozói fe- 
lület. Ezt használta ki többek között a később megjelent 
Systems Management Server 2.0 is. A Windows 2000, majd az 
XP megjelenésével a WMI tovább bővült, fejlődött, de a lehe- 
tőségek igazán csak a programozó kedvű rendszergazdák szí- 
vét dobogtatták meg. A WMI, mint rendszerszolgáltatás a Win- 
dows 2000-től kezdődően minden Windowsnak (a Millenium- 
nak is) része, a jelenlegi legújabb WMI-támogatás Windows 
95-98-NT4-hez pedig letölthető a Iwmicorel] címről. 

És hogy mindez mire jó? Nos, rendszergazdai jogok birtokában 
(merthogy ez mégiscsak egy rendszerfelügyleti eszköz), akár 
távoli gépről is, a legapróbb részletekig lekérdezhetjük a hard- 
ver- és szoftverkörnyezet tulajdonságait, sőt sok esetben módo- 
síthatjuk is azokat. 











[elüt ee s 
Microsoft Windows [Wersion 5.2. 
KC) Copyright 1985-2093 Microsoft Corp. 


:Xfumic /node:ru2083xp desktopmonitor get screenwidth. 
sscreenheight 


ScreenHeigi creenyid 
698 808 


:Ndwmic /node:w2803xp, guotasetting aza 
da 


property(s? 5 
ng .VolumePath-VCrNx"t 
PPropertyCs) update successful. 















RÖOTNCIMU2 :U/ -Öperatíngőysten.Namez! 
P ProfessionaltC:XSUINDOÚS ! evicexsHard 
diskovvPartition1")—oMin32Shutdoun() 

thod execution successful. 
Out Parameters: 
instance of . PARAMETERS 


ReturnUalue - 8; 





B 


EJ Kedvcsinálónak: távoli Windows XP munkaállomás 
képernyőfelbontásának lekérdezése, a C:N meghajtón 
alkalmazott kvóta bekapcsolása, illetve a Windows 
leállítása — egy-egy sorban 


A WNI felépítése, működése 


Ahhoz azonban, hogy a fenti parancsokat csuklóból adjuk ki, 
meg kell ismernünk a WMI belső felépítését. A WMI nagyon 
univerzális: ugyanolyan módon kérdezhetjük le a router hűtő- 
ventillátorának fordulatszámát (persze csak ha a router ezt lesz 


Watt űl ü.§ tá TE d GW § 





kedves elárulni nekünk), mint ahogyan a Windowsra telepített 
hotfixek listáját. Az univerzális működés feltétele viszont egy 
séma, aminek segítségével , megfoghatjuk" a kezelni kívánt 
eszközöket -— legyen az hardveres, vagy szoftveres elem. Ehhez 
a WBEM-szabvány kialakításakor a készítők elkészítettek egy 
információs modellt, sémát, ez a CIM (Common Information 
Model). A séma rengeteg eszköz definícióját tartalmazza, még- 
pedig osztályhierarchia formájában (azaz nem ússzuk meg itt 
sem az objektumorientált felfogást, az osztály, egyed, öröklés 
fogalmát. Ez a modell egyébként tovább is bővíthető, és ezt a 
Microsoft meg is tette, természetesen az eredeti CIM-re alapoz- 
va — a Microsoft által elkészített bővítményben természetesen 
leginkább a Windows-specifikus objektumosztályokat találjuk 
meg. Hogy kicsit világosabb legyen, miről beszélünk, lássunk 
egy példát. A Windows CD-ROM meghajtóját jelképező 
Win32 CDROMDTrive osztály családfája az alábbiak szerint 
vezethető le: 











CIM ManagedSystemElement 


CIM LogicalElement 
CIM LogicalDevice 





CIM MediaAccessDevice 
CIM. CDROMDrive / ( CIM DiskDrive ) 








WIN32 CDROMDrive 





WIN32 DiskDrive 








d A Win32 CDROMDrive családfája 


A Win32 CDROMDTrive osztály tehát közvetlenül a 
CIM CDROMDTrive leszármazottja, de a családfáját visszave- 
zethetjük például a CIM LogicalDevice osztályig is. Hogy mi 
értelme van ennek az öröklésnek? Minden osztálytípus saját 
jellemzőket definiálhat, de örökli a szülőktől származó jellem- 
zőket is. A Win32 CDROMDrive például rendelkezik egy 


ch.net 





,Caption" jellemzővel (ami a meghajtó szöveges azonosítója) 
—- ezt még a CIM ManagedSystemElement , ősétől" örökölte; 
de ugyanígy van például , VolumeName" (kötetnév) jellemző- 
je is, ami pedig a Win32 CDROMDTrive osztály sajátja. Azért 
ne ijedjünk meg túlságosan: az esetek nagyon nagy százaléká- 
ban csak a , kész", általában Win32. ... objektumokat használ- 
juk fel, ráadásul a wmic.exe még tovább egyszerűsíti majd a 
dolgunkat. 


Osztályok és egyedek 


Az eddigiekben a különféle objektumok modellezéséhez hasz- 
nált osztályhierarchiáról volt szó. Az osztályok (class) azonban 
önmagukban nem használhatók a valódi objektumok kezelé- 
séhez. A menedzselt objektumot valójában jelképező fogalom 
az ,egyed" (instance). Természetesen minden egyed valame- 
lyik osztályba tartozik, és jelképez egy-egy, a valóságban is lé- 
tező objektumpéldányt. Tegyük fel például, hogy a rendsze- 
rünk két CD-ROM-meghajtót tartalmaz. A sémában 
Win32 CDROMDTive osztály természetesen ekkor is csak egy 
van, — viszont a  WMI adatbázisában ekkor két 
Win32 CDROMDrive osztályú egyed található. Ha csak az 
egyik CD-ROM-meghajtó jellemzőire vagyunk kíváncsiak, ki 
kell választanunk azt az egyedet, amely az adott objektumot 
jelképezi. 

Hogyan különböztetjük meg egymástól az osztály- és egyed- 
objektumokat? Ha bárhol egyszerűen az osztály nevére hivat- 
kozunk, természetesen az osztályobjektumról beszélünk. Az 
egyedek megkülönböztetéséhez viszont meg kell értenünk 
még egy fogalmat. Minden osztály tartalmaz egy, úgynevezett 
kulcs (key) jellemzőt, aminek értéke minden egyes egyed ese- 
tében (nomen est omen) egyedi. Hogy az adott osztálynak me- 
lyik jellemzője a kulcs, az osztály definíciója dönti el. A 
Win32 CDROMDTrive osztály esetén ez például a , DevicelD". 
A kulcsjellemző segítségével mindig pontosan nyakoncsíphet- 
jük a kívánt objektumot. 


Írható jellemzők és metódusok 


Az objektumok jellemzői közül a legtöbb csak olvasható típu- 
sú (gondoljunk csak bele, egy memóriamodul méretét például 
nincs sok értelme módosítani), de akad néhány írható is. Az 
objektumok a jellemzők mellett eljárásokkal, metódusokkal is 
rendelkeznek; ezeket az eljárásokat a WMI alrendszer értelme- 
zi és hajtja végre. A rendszerszolgáltatásokat jelképező 
Win32 Service osztályú egyedek például rendelkeznek Start- 
Service és StopService metódusokkal; ezek meghívása elindít- 
ja, illetve leállítja az adott szolgáltatást. A metódusok többsé- 
gét az egyedeken hívjuk meg (hiszen például egy konkrét szol- 
gáltatást szeretnénk leállítani), de előfordulhat az is, hogy egy 
osztályobjektum metódusát hívjuk meg (ilyen például a 
Win32 Process osztály Create metódusa). 


A WOL lekérdezőnyelv 

A WOL (WMI Cuery Language) nyelvet arra fejlesztették ki, 
hogy segítségével egyértelműen hivatkozhassunk egy adott 
osztály adott egyedére. A nyelv viszonylag egyszerű, és hason- 
lít az SOL-re. Az egyszerűbb lekérdező WOL-utasítások szin- 
taxisa így alakul: 





TA cosztályz: a WMI osztály neve 
A cjellemzőz: a fenti WMI osztály egy jellemzőjének neve 


tech.net GEPET ágz úg 


BA zoperátors: —, c5, c, 5, cz, 5z, IS, IS NOT 
(utóbbi kettő csak a Null értékkel) 
TA dogikai művelets: AND, OR, NOT, stb. 


Néhány példa: 
TA A rendszerben található összes Win32 CDROMDrive 
osztályú egyed: 





HA Az ,Administrator" felhasználói fiókja: 


- Iogiossameried jalahóntajiazspuag / cm 0 p UI m 


HA Az összes éppen futó processz, amelynek prioritása na- 
gyobb, mint 8: 


A WOL-ből kezdésnek ennyi elég is (a további finomságokra 
később még visszatérünk). 


Ismerkedés a wmic.exe paranccsal 


A Windows 2003 Server wmic.exe parancsa megkönnyíti a 
WAMI használatát. Maga a parancs az egészen egyszerű ,egy- 
sorosoktól" ez egészen összetett, formázott XML kimenetű 
adatgyűjtésig nagyon sok mindent tud. Kezdjük a legelején! A 
parancsnak két üzemmódja van: az interaktív és a non-interak- 
tív mód. A működése persze mindkét módban ugyanaz, a kü- 
lönbség mindössze annyi, hogy interaktív módban belépünk a 
WMIC , promptba", majd ott is maradunk addig, amíg ki nem 
adjuk az exit vagy guit parancsot: 





A másik, non-interaktív módban a parancsot a wmic.exe para- 
métereként adjuk át. A WMIC ilyenkor végrehajtja az utasítást, 
majd rögtön ki is lép: 





A továbbiakban — hacsak külön nem jelezzük — a non-interak- 
tív módot használjuk. 


Szükséges jogosultságok a WMIC helyi futtatásához 


A WMIC parancsot rendszergazdai jogokkal futtathatjuk. Ha a 
felhasználó nem rendszergazda, az alábbi jogosultságokkal 
kell rendelkeznie: 


A Teljes írásjog a HKLMNSoftwareMicrosoftlwWBEM il- 
letve a HKLMNSoftwarelMicrosoftVVWV/BEMNWMIC re- 
gistry kulcsokra 8 

"A Teljes írásjog a root/cli illetve root/cimv2 névterekre. 


A WNMI névterekre a folytatásban még visszatérünk. A névterek 
hozzáférési jogait a Computer Management eszköz Services 
and Applications  WMI Control " Properties — Security ol- 
dalon állíthatjuk be. Itt válasszuk ki a RootNCIMv2 illetve a 
RootNCli névtereket és kattintsunk a Security gombra. 
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B CI DEFAULT 

E II drectoy 

E CI Microsolt 

E CI MictosoltáciiveD rector 
B CI MicrosoltoNS 


E CI MiciosottNL8 
B CI MsCiuster 
E CI permon 
BI Pokey 

- 5. RSOP 

5. CI SECURITY 
I ndbscigtion 
BEI wa 





E Hozzáférési jogosultságok a WMI névterekhez — a 
rendszergazdának , gyárilag" megvan 


WMIC aliasok 


A szemfüles olvasónak már nyilván feltűnt, hogy a fenti pél- 
dákban az operációs rendszer néhány jellemzőjét kérdeztük 
le. Igen ám, de milyen osztály jellemzőiről van szó? Hol van itt 
a CIM séma? Mi az az ,os" osztály? Nos, az ,os" osztály való- 
ban nem létezik, a lekérdezések a háttérben a Win32 Opera- 
tingSystem egyetlen létező egyedének jellemzőire vonatkoz- 
tak. Az ,os" egy alias, amivel a WMIC igyekszik megkönnyíte- 
ni a rendszergazda munkáját. Alapértelmezésben mintegy 80 
ilyen alias létezik, az aliasok listáját és ,magyarázatát" a 
wmic.exe /? parancs elárulja nekünk. Ha még konkrétabban 
szeretnénk tudni, mi történik az aliasok feloldásakor, írjuk be: 





A fenti parancs lekérdezi az ,os" nevű alias-objektum (mert ez 
is egy WMI-egyed!) target paraméterét, és lám, máris egy WOL 
lekérdezésbe futottunk! Innentől már világos a kép: amikor a 
WAMIC-ben az ,os" aliast használjuk, valójában a Win32 Ope- 
ratingSystem osztály egyedeit kezeljük (még szerencse hogy 
ebből csak egy van), Ez a lekérdezés (amiben az ,os" helyére 
tetszőleges másik aliast is behelyettesíthetünk, még magát az 
valias"-t is :-) ) elárulja nekünk, hogy igazából melyik osztály 
egyedeivel van dolgunk, és hogy azt hol keressük a WMI osz- 
tályok leírása között, a WMI referenciában (a referencia web- 
címe: [wmiref)). 


Objektumok jellemzőinek lekérdezése: a get művelet 


A WMIC utasításban először az objektum(okjra utaló aliast, 
majd a velük végezni kívánt műveletet kell megadnunk. A 
,Bet" művelet az objektumok jellemzőinek lekérdezésére szol- 
gál. A művelet után meg kell adnunk a lekérdezni kívánt jel- 
lemzők nevét (több jellemző esetén vesszővel elválasztva): 





A WMIC az adatokat , belül" XML formátumban kezeli. Az, 
hogy ennek eredményét mi milyen formában látjuk, az adott 
alias alapértelmezett beállításaitól függ. Az eredmény formátu- 
mát mi is meghatározhatjuk a get művelet /format kapcsolója 
segítségével. A /format után meg kell adnunk a kívánt formá- 
tum nevét (vagy a formátum elkészítéséhez használt .xsl fájl 
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nevét), ami alapértelmezésben a következők valamelyike lehet 
(súgó: wmic os get /format /?): 





by IKJLG E 
csv Vesszővel elválasztott értékek, soronként egy egyed 
hform HTML táblázat, minden érték új sorban 





htable . HTML táblázat, minden sor egy egyed, minden érték 

egy oszlop 

hmof " MOF formátum (HTML-ben) 

hxml — XML formátum (HTML-ben) 

list Szöveges kimenet, soronként egy jellemző neve és 
értéke 

table — Szöveges, soronként egy egyed, oszloponként egy 
jellemző értéke 

value — Mint a list 

rawxml Valódi XML, a lekérdezés eredményének eredeti for- 
mája (irányítsuk .xml kiterjesztésű fájlba, így az IE 
megnyitja nekünk). A fájl tartalma egyébként nagyon 
sokat elárul a WMIC működéséről. 























A WMIC kimenetének formátumai (/format: kapcsoló) 


Próbáljuk ki a különböző formátumokat például az alábbi pa- 
rancs segítségével: 





wmic group get name 


format : cformátumnévs —— ! 


Ha nem adunk meg formátumot, akkor az adott alias, illetve az 
adott lekérdezés típusának megfelelő formátumban kapjuk az 
eredményt (ez általában a list vagy a table). 
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E A csoportok listája HTML formátumú kimenetben 


Ilyen kimenet-formázió XSL fájlt egyébként mi magunk is elő- 
állíthatunk (lásd később). 


A get művelet további kapcsolói 


A [format mellett a get és a list művelet további kapcsolókat is 
támogat, többek között: 
TA value: az egyed összes jellemzőjének értéke, a kime- 
net , value" formátumú 
TA /all: az egyed összes jellemzőjének értéke, a kimenet 
table" formátumú 
TA /every:cmp3: a lekérdezés megismétlése ,mp" másod- 
percenként 
a /el:full]l: az osztály jellemzőinek listázása (a :full meg- 
adása esetén magyarázattal együtt, például: 
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Objektumok jellemzőinek listázása: a list művelet 


Az objektumok jellemzőit a "list" művelet segítségével is lekér- 
dezhetjük. A különbség annyi, hogy míg a get műveletnél mi 
magunk határozhatjuk meg a lekérdezendő jellemzőket, a list 
parancsban "csomagok" vannak, ezek pedig az alábbiak (azt, 
hogy melyik alias esetén melyik csomagban pontosan melyik 
jellemzők vannak, a wmic caaliasz list /? paranccsal tudjuk 
meg): 
TA brief: az osztály legfontosabb jellemzői 
A full: az osztály összes jellemzője (ez ugyanaz, mintha a 
get /all utasítást adtuk volna ki) 
TA instance: az egyedi jellemzők listázása 
TA status: státuszjellemzők, állapotjellemzők 
TA system: rendszerjellemzők 
A writeable: az írható jellemzők 
TA egyéb: az alias egyedi jellemzőcsomagjai (lásd az adott 
alias helpjét) 


A list művelet a get-hez hasonlóan támogatja az /every és /for- 
mat kapcsolókat is. Néhány példa: 





Egy adott egyed kezelése (WHERE paraméter) 


Láthattuk, hogy az aliasok a rendszerban található, adott 
osztályú egyedek sokaságát adják vissza (SELECT " FROM 
sosztály5). A lekérdező jellegű műveletek esetén ezzel általá- 
ban nincs is különösebb baj, legfeljebb a válasz kicsit bősége- 
sebb lesz a vártnál és mazsoláznunk kell. Vannak helyzetek 
azonban, amikor ez nem engedhető meg, és egészen pontosan 
ki kell választanunk a kívánt egyedet. Ehhez a VVMIC WHERE 
paraméterét használhatjuk, amit közvetlenül az alias neve után 
kell megadnunk, például: 





Ami nem is túl meglepő, ha visszagondolunk arra, hogy egy 
alias valójában nem más, mint egy WOL lekérdezés , eleje". A 
WHERE paraméterben persze sokkal bonyolultabb és összetet- 
tebb feltételeket is megadhatunk, csak két dologra vigyázzunk: 
TA Ha a feltétel speciális karaktert (-, /, stb.) tartalmaz, az 
egész WHERE után következő feltétellistát tegyük idé- 
zőjelek közé (ez jó ha szokásunkká válik, mert sok 
bosszúságtól kímélhet meg a későbbiekben!) 
TA A backslash (V karaktert mindig duplázva írjuk 


A kimenet átirányítása (WMIC kapcsolók) 


A parancs kimenetét fájlba irányíthatjuk a klasszikus módon 
(2), vagy használhatjuk a wmic parancs /output illetve /append 
kapcsolóját (előbbi felülírja, utóbbi hozzáfűzi a kimenetet), a 
következő értékekkel: stdout (képernyő, alapértelmezés), clip- 
board (a Windows vágólap), vagy fájlnév, például: 
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Figyeljük meg, hogy a WMIC kapcsolóját a wmic 
utasítás, a get művelet kapcsolóit pedig a művelet pa- 
raméterei után adtuk meg. 


Jellemzők beállítása: a set művelet 


Lekérdezni már tudunk, most következzen a beállítások módo- 
sítása. A WMI objektumok egy része nem túl sok írható jellem- 
zőt tartalmaz, de ezeket lekérdezhetjük például a 





parancs segítségével. A bootmenü várakozási idejének átállítá- 
sa például így fest: 





A set művelet után az átállítani kívánt jellemző nevét és érté- 
két egyenlőségjellel kell megadnunk. Több jellemző módosítá- 
sa esetén az ,egyenletek" közé vesszőt kell tenni. Ha egy adott 
aliasból (osztályból) több, mint egy egyed létezik, persze hasz- 
nálnunk kell a WHERE paramétert is: 





A fenti parancs a C:N meghajtón bekapcsolja a kvótarendszert 
(mégpedig úgy, hogy meg is akadályozza az írást azok számá- 
ra, akik átlépik az engedélyezett értéket); az alapértelmezett 
kvótát pedig 10MB-ra állítja be. A State jellemző értéke a refe- 
renciával ellentétben nem szöveges, hanem számszerű, de in- 
direkt módon könnyen kikísérletezhető, hogy melyik érték mit 
jelent (hiszen lekérdezni ugye már tudunk?) 


Metódusok hívása: a call művelet 


A WMIC , call" műveletének segítségével az objektumok me- 
tódusait hívhatjuk meg (persze amennyiben az adott objektum- 
nak létezik metódusa). A call műveletnek nincsenek speciális 
paraméterei, a call után egyszerűen csak át kell adnunk a meg- 
hívni kívánt metódus nevét, majd vesszővel elválasztva az 
esetleges paramétereket. Az egyes aliasok (osztályok) esetében 
hívható metódusok listáját természetesen a 
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parancsok valamelyikével csalhatjuk elő. A metódusok meghí- 
vása azonban már nem ennyire értelemszerű. A call művelet 
ugyanis egyedekre értelmezendő, ezért ha elfelejtjük a VV/HERE 
használatát, a parancs hibát fog okozni (az nem baj, ha a 
WHERE kitétel több egyedet ad vissza, ilyenkor a metódus 
minden visszaadott egyedre meghívódik). A másik dolog, ami 
nehezíti a metódusok hívását, hogy a /? visszaadja ugyan a me- 
tódus paramétereinek listáját és azok típusait, de lehetséges ér- 
tékeit nem! Ezért legkésőbb a metódusok hívásánál elkerülhe- 
tetlen, hogy fellapozzuk a WMI referenciát [wmiref] és megke- 
ressük benne a metódus pontos leírását. A 


paranccsal indítsunk például néhány Számológépet, majd a 
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paranccsal szépen, egy lépésben ki is lőhetjük őket. 
A process alias (Win32 Process osztály egyedei) Ter- 
minate metódusa paraméter nélkül használható, és a 
Create metódusnak csak egy kötelező paramétere 
van, mégpedig az indítani kívánt processz neve. 
Figyeljük meg, hogy a Create hívásakor nem használtuk a 
WHERE paramétert, mert a Create metódus nem kötődik szigo- 
rúan az egyedekhez. A processz leállításához (Terminate) vi- 
szont már meg kell mondanunk, hogy pontosan melyik egye- 
dekre gondoltunk. Példa egy paraméterezett metódushívásra: 


Ha több átadandó paraméterünk van, azokat vesszővel elvá- 
lasztva kell felsorolnunk a metódus neve után. 


Műveletvégzés távoli gépen (WMIC kapcsolók) 


Itt az ideje, hogy kimozduljunk saját számítógépünk hatósuga- 
rából. A WMIC távoli számítógépek esetén is működik, 
amennyiben a WMIC-t futtató ,kliens" és a felügyelt , szerver" 
gép között Windows hálózati kapcsolat (DCOM, RPC) építhe- 
tő ki. Jogosultság szempontjából ugyanaz igaz, mint a helyi fel- 
használásnál: helyi rendszergazdai jogokkal kell rendelkez- 
nünk. Ha Windows tartományban vagyunk, és a WMIC-t tarto- 
mányi rendszergazdaként futtatjuk, nem fog meglepetés érni. 
Fontos, hogy a WMIC-nek nem kell a célgépen telepítve len- 
nie, elég, ha ott a WMI szolgáltatás fut. 

A távoli menedzsment három legfontosabb kapcsolója a /node, 
a /user és a /password: 


A /user és a /password kapcsolók önmagukért beszélnek. A 
/node: kapcsoló után, vesszővel elválasztva kell megadnunk a 
kezelni kívánt számítógép(ek) nevét vagy IP címét. A listába 
felvehetünk szöveges fájlokat is, ekkor a fájl neve elé €-ot kell 
írnunk. A fájl természetesen számítógépneveket tartalmazzon, 
soronként és/vagy soron belül vesszővel elválasztva egyet- 
egyet. Kiragadott példa a súgóból: 


Ennyit mára az elméletből, következő számunkban innen foly- 
tatjuk. Lazításképpen bemutatunk egy hasznos metódust, illet- 
ve annak részletes használatát: 


Felhasználó kijelentkeztetése, számítógép leállítása vagy 
újraindítása 

A fentieket mind-mind megtehetjük a Win32. OperatingSystem 
osztály Win32Shutdown metódusával. A cikk elején is látott 
példa a W2003XP nevű számítógépet állítja le, mégpedig kö- 
nyörtelenül: 


A Win32Shutdown metódusnak egy értékes paramétere van, 
ami a követendő eljárást jelzi: 


[daCA Leírás 




















6 — Újraindítás rákérdezés nélkül (Forced Reboot) 
8 Kikapcsolás (Power Of) 
.8-4-12 Kikapcsolás rákérdezés nélkül (Forced Power Of) 














A rákérdezés nélküli műveletek esetén a Windows nem várja 
meg, hogy a felhasználó elmentse a munkáit, hanem azonnal 
végrehajtja a műveletet. 


Végül egy jótanács a folytatásig: az alábbi parancsot: 


csak akkor próbáljuk ki, ha előtte mentettünk ;-)! 





Folytatjuk... 


Fülöp Miklós 
mickCnetacademia.net 





Kapcsolódó tanfolyamaink: 


http://technet.netacademia.net/go? 
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A Microsolt Exchange 2000 


útválasztása 


Az üzenetek útja egy szervezeten belül 


és kívül 


Egy szervezetben már két Exchange kiszolgáló esetén is felmerül a kérdés: merre mennek az elküldött 
üzenetek? Gyakran nem is tudja a rendszergazda, mi történik tulajdonképpen több kiszolgáló esetén. 
A cikkben szó lesz az üzenetek útjáról, az útválasztásról, és az összefüggésekről. 


Az alapok 


Ahhoz, hogy Exchange 2000 környezetben megértsük az útvá- 
lasztást, meg kell ismerkednünk néhány alapvető dologgal, 
például az útválasztócsoportokkal, a csatolókkal és az állapot- 
jelző táblázattal. Menjünk szépen sorban, a cikk a végére fog 
igazán kikerekedni. 

Az Exchange 2000 telepítésekor automatikusan létrejön egy 
alapértelmezett útválasztócsoport az Adminisztatív csoporton 
belül és - nem újdonság — First Routing Group lesz a neve. Eb- 
be kerül bele rögtön az első kiszolgáló, és ha nem hozunk lét- 
re több útválasztási csoportot (mert nem kötelező ám), minden 
további kiszolgáló is ebbe a csoportba fog kerülni. 


Mikor érdemes több útválasztócsoportot (Routing Group) 
létrehozni? 


Amikor valóban több telephelyen szétszórva vannak a kiszol- 
gálóink, köztük a kapcsolat nem állandó (nem — úgymond — 
LAN szintű, nem megbízható és/vagy nem gyors). Persze más 
érvek is vezérelhetnek bennünket, például a levélforgalom sza- 
bályozása a kiszolgálók közt. Másként megy a kiszolgálók köz- 
ti üzenetforgalom, ha azok egy, és másként, ha két különböző 
csoportban vannak. 

Egy útválasztócsoporton belül a kiszolgálók közvetlenül be- 
szélgetnek egymással, mindenki mindenkivel. Ezt a forgalmat 
nem lehet időzíteni, azonnali a végrehajtás. 

A képen is ez látszik, minden kiszolgáló az összes többivel 
közvetlen kapcsolatban áll: 





B Üzenettovábbítás útválasztócsoporton belül 
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Ha viszont két különböző útválasztócsoportban levő kiszolgá- 
ló akar beszélgetni, bizonyos szabályokat be kell tartaniuk, és 
valószínű, hogy közvetlenül nem is tudnak kommunikálni, ha- 
nem az úgynevezett Bridgehead kiszolgálókon keresztül tehe- 
tik azt meg. A Bridgehead kiszolgálókat csatolók kötik egymás- 
hoz. Jól mutatja ezt a következő ábra is: 





Bridgeheadek 





E Egy üzenet útja 


Tegyük fel, hogy Júzer Jolán (akinek a postaládája az A jelű ki- 
szolgálón található), levelet küld Teszt Eleknek (akinek pedig a 
D jelű kiszolgálón vannak a levelei). A következő lépések tör- 
ténnek: 

1. Az A jelű kiszolgáló észleli, hogy bizony másik útválasztó- 
csoportba szól a levél, ezért megkeresi a megfelelő bridge- 
head kiszolgálót és passzolja neki a levelet. Ez a példában 
a B kiszolgáló. 

2. AB kiszolgáló - bár át tudja küldeni a másik útválasztócso- 
portba a levelet — nem közvetlenül D-vel tárgyal, hanem a 
C kiszolgálónak küldi tovább az üzenetet, mert vele áll 
közvetlen kapcsolatban. 

3. AC jelű kiszolgáló fogadja a levelet, és közvetlenül D-nek 
fogja elküldeni, hisz ők már egy útválasztócsoportba tar- 
toznak. Végül Teszt Elek postaládájában landol a levél. 


Olyan környezetben, ahol Exchange 5.5 és Exchange 2000 él 
együtt, az útválasztócsoportoknak kicsit más az értelmezése. 
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:" Az üzenetek útja egy szervezeten belül és kívül / LK 


A Microsoft Exchange 2000 útválasztása 


Egyrészt egy csoportban nem lehet több Adminisztra- 
tív csoportból kiszolgáló, másrészt az Exchange 5.5 
az Exchange 2000 Administrative Groupokat siteok- 
nak képzeli — az útválasztócsoportok számára nem is 
léteznek. 

Exchange natív módban, vagyis amikor már csak Exchange 
2000 kiszolgálók vannak a szervezetben, egy útválasztócso- 
portban több adminisztratív csoportból származó kiszolgáló is 
szerepelhet. 


Érdemes tisztázni, mikor tartozhatnak a kiszolgálók azonos 

csoportba: 

1. Ha a kiszolgálók megbízható, állandó, közvetlen hálózati 
kapcsolatban állnak egymással (ez tipikusan LAN-t jelent) és 

2. ugyanabban az Active Direcory erdőben vannak, valamint 

3. közvetlen SMTP kapcsolatot tudnak teremteni egymással 


Másik útválasztócsoportban levő kiszolgálóval Bridgehead és 
Routing Group Master kiszolgálókon keresztül kommunikálnak. 


Kommunikáció az útválasztócsoportok közt 


Az útválasztócsoportok közt a kommunikáció nem automati- 
kus. Amikor létrehozunk több útválasztócsoportot, gondoskod- 
ni kell a köztük levő kommunikációról is. Alapvetően az üze- 
nettovábbítás a Bridgehead kiszolgálók közbeiktatásával, csa- 
tolókon (Connector) keresztül történik. A csatoló olyan, mint 
egy ,kábel" két szerver között, amelyen SMTP adatforgalom 
zajlik. Háromféle csatolót tehetünk két útválasztócsoport közé: 

HA Routing Group-csatoló 

HA SMTP-csatoló 

H X400-csatoló 


A csatolók (,kábelek") végein található kiszolgálókat Bridge- 
headeknek (hídfő) nevezzük. Egy kiszolgáló (virtuális SMTP szer- 
ver) többszörös Bridgehead is lehet, és egyszerre több szerver 
(akár mindegyik) is lehet Bridgehead egy útválasztócsoportban. 


Routing Group Connector 


Az útválasztócsoportok összekötésére legegyszerűbben a Rou- 
ting Group-csatoló használható (Routing Group Connector). 
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Kézenfekvő megoldás mert: 

JA Több Bridgehead kiszolgáló lehet egy csatoló mindkét 
végén, ezért több Exchange kiszolgáló esetén hibatű- 
rést illetve terheléselosztást is tudunk biztosítani. 

HA A csatoló által használt kommunikációs protokoll alap- 
vetően az SMTP (például, ha a csatoló mindkét végén 
Exchange 2000 van - vagy egy Exchange 5.5 kiszolgá- 
ló IMC-vel). 

HA Képes RPC-vel is kommunikálni, ha egy Exchange 
2000-et Exchange 5.5-tel szeretnénk összekötni. Ebben 
az esetben egyébként Exchange 5.5 oldalról Site Con- 
nector szükséges a működéshez. 

HA A csatoló működése időzíthető, így jól használható, ha 
például nagyméretű állományok továbbítását éjszakára 
szeretnénk időzíteni. 

A A csatolón szintén korlátozhatjuk, ha csak rendszer- 
üzenetek (pl. nyilvános mappák replikációja) vagy 
egyéb üzenetek továbbítását szeretnénk biztosítani. 


Hátránya, hogy biztonsági beállításokat nem tesz lehetővé. (Ha 
például SSL-lel szeretnénk levelezni, azt a virtuális kiszolgáló 
szintjén kell beállítani.) Ugyanakkor megjegyzem, hogy a leve- 
lek formátuma nem sima szöveg, hanem TNEF (Transport Ne- 
utral Encapsulation Format), így avatatlanok nem olyan 
könnyen férnek hozzá az elkapott csomagok tartalmához. 


SMTP Connector 


Főként akkor érdemes használni, ha 

H Exchange 5.5-ös IMC-vel felszerelt másik útválasztó- 
csoportban levő kiszolgálót szeretnénk a csatoló másik 
végén látni. 

HA ETRN vagy TURN segítségével szedjük a leveleket az 
egyik telephelyen a másikról (elképzelhető, hogy egy 
vidéki telephely nem állandó, hanem ISDN kapcsolat- 
tal van összekötve a központi telephellyel, és a levele- 
ket a vidéki kiszolgáló időnként ETRN-nel szedi le.) 

A a csatoló szintjén SSL-t szeretnénk használni. Ekkor 
csak az SMTP-csatolót használhatjuk 
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A Routing Group-csatolóval szemben itt csak a helyi Bridge- 
head kiszolgálókat tudjuk megadni. Érthető is, hiszen alapve- 
tően MX rekordok alapján tájékozódik a csatoló. 

Ezen kívül lehetőség van smarthost beállítására, amikor a ki- 
szolgáló minden levelet egy másiknak továbbít. Amikor két út- 
választócsoport közt SMTP-csatolót hozunk létre, figyelmeztet 
is a System Manager, hogy a másik útválasztócsoportban levő 
kiszolgálót kell megadnunk smarthostnak a két útválasztócso- 
port közti kommunikáció biztosításához. 


A beállítás bonyolultsága miatt csak akkor érdemes SMTP-csa- 
tolót használni, ha valóban olyan funkcióra van szükségünk, 
amit a Routing Group Connector nem tud biztosítani. 


X.400-csatoló 


A jó öreg X.400-as csatoló hasznos lehet, ha olyan telephelye- 
ket szeretnénk összekötni, amelyek közt igen kicsi az átviteli 
sebesség, de azért megbízható. Az X.400-csatoló jól működik 
nagyméretű levelek esetén is, kicsi átviteli sebesség esetén. 
Ugyanakkor beszédesebb protokoll, mint az SMTP, gondoljuk 
tehát meg a választását. Ha az útválasztócsoportokat, telephe- 
lyeket X.25 köti össze, csak ez használható. 

Kétirányú kapcsolat kiépítéséhez két egyirányú csatoló felépí- 
tése, beállítása szükséges. 


A Link State Table 


A szervezetben levő kiszolgálók mindegyikén található egy 
táblázat, ami az összes lehetséges utat, és annak árát (cost) is 
tartalmazza. A kiszolgálók mindegyike használja a táblázatot, 
útvonalat néz ki belőle, merre küldje az üzeneteket. A Link 
State Table tartalmazza a lehetséges utakat, a csatolók állapo- 
tát (Up vagy Down), és az árat is. Az Exchange takarékoskodik, 
mindig a legolcsóbb utat választja az üzenetek továbbításánál. 
A Link State táblázat minden kiszolgálón megtalálható. De ho- 
gyan terjeszti az Exchange ezt a táblázatot a kiszolgálók 
közt...? 


A Routing Group Master 


Amikor szétosztjuk a kiszolgálókat a különböző útválasztó- 
csoportokba, az első kiszolgáló lesz a főnök (Master) a cso- 
portban. A Routing Group Master elsődlegesen az útválasztá- 
sért felelős, ő az, aki a Link State tábla frissítését és terjeszté- 
sét végzi. 


A Link State táblázat terjesztése 


Mindig, minden kiszolgáló résen van, és figyeli a csatolók 
állapotát. Amint egy csatolón keresztül nem tud levelet külde- 
ni, rövid időn belül megváltoztatja a saját Link State tábláját, 
és a változásokról értesíti a saját csoportjában levő Routing 
Group Mastert. Mindez a 691 TCP porton keresztül történik, 
SMTP protokollal, de nem levélben. A Routing Group Master 
feladata egyrészt, hogy a saját csoportjában levő egyéb kiszol- 
gálókat értesítse, másrészt a Bridgehead kiszolgálókon keresz- 
tül eljuttatja a megváltozott táblázatot a többi útválasztócso- 
portba. A csoportok közt a Link State tábla a 25-ös TCP porton 
keresztül jut el, de nem SMTP üzenet formájában, hanem köz- 
vetlen a X-LINKZSTATE SMTP paranccsal. 


! 
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Lássunk egy konkrét példát a Link State tábla-változás szétkür- 
tölésére a fenti ábra segítségével: 

Az XCH2 szeretne levelet küldeni XCH5-nek. Igen ám, de a két 
útválasztó közti kapcsolat éppen nem működik, és ezt az 
XCH2 észre is veszi. 


1. Az XCH2 értesíti erről a saját Routing Group Masterét, per- 
sze előtte a saját Link State tábláját frissíti 

2. A Routing Group Master is megváltoztatja a Link State táb- 
lát, és elküldi mindenkinek a saját útválasztócsoportjában. 

3. A Bridgehead kiszolgáló elküldi a szomszédos útválasztó- 
csoportokba a fírissített táblát. 

4. A Bridgehead kiszolgáló frissíti a saját tábláját, majd elkül- 
di a táblát a Routing Group Masternek. 

5. A Routing Group Master szétkürtöli a saját csoportjában. 


A változás végiggyűrűzik az összes útválasztócsoporton, 
előbb-utóbb mindenki értesül a változásról. Az egész folyamat 
elég gyors, a legelső Routing Group Master már 5 perccel a 
változás után tud róla. 
Van pár eset, amikor a linkek sosem váltanak át Down állapot- 
ba. Ezek a következők: 


HA SMTP-csatoló esetén ha DNS alapokon (az MX rekor- 
dok segítségével) kommunikálunk. 

A Ha Routing Group-csatolón keresztül bármelyik kiszol- 
gáló küldhet levelet, vagyis ahhoz a csatolóhoz hely- 
ben mindenki Bridgehead. 


A WinRoute nevű programmal (amely az Exchange 2000 tele- 
pítő CD-n található) a Link State tábla tartalmát belülről is meg 
lehet nézni. 
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E WinRoute - a Link State tábla tartalma 


WinRoute segítségével a szervezetben bármely távoli kiszol- 
gáló Link State táblája megtekinthető, nem csak a helyi ki- 
szolgálóé. 


Útválasztás 


Végül rakjuk össze a kirakó darabjait! 

Van több útválasztócsoportunk, mindegyikben Exchange ki- 
szolgálókkal. Ha a Link State tábla alapján egy kiszolgáló több- 
felé is küldheti a levelet, mégis mi alapján dönti el, merre in- 
dítsa? 

Az Exchange útválasztását befolyásoló tényezők: 

H Az útba eső linkek mindegyike élő-e — ezt a Link State 
tábla alapján dönti el az Exchange. 

HA Az útba eső összes link beállítása engedélyezi a levél 
továbbítását (például ha egy csatolón a küldhető levél- 
méretet korlátozzuk, ugyanakkor a küldendő üzenet 
nagyobb a megengedettnél). 

HA Ha a névtér alapján két lehetséges csatoló is rendelke- 
zésre áll, amelyen mehetne az üzenet, akkor a legjob- 
ban hasonlítót fogja választani a kiszolgáló. 

A Merre a , legolcsóbb" elküldeni az üzeneteket — A Link 
State tábla , Cost" oszlopából számolja ki az Exchange. 


Megpróbálom konkrét példákon szemléltetni az útválasztást és 
a levéltovábbítást. 


RGC A-B 
(Cost-1) 









RGC A-C 
(Cost-1) 


SMTP B 
(Cost-10) 





RGC B-C 
(Cost-5) 


Az ábrán három telephelyet láthatunk: A, B és C. Ha minden 
kapcsolat élő, a levéltovábbítás elve az, hogy a két Internetki- 
járat ellenére elsősorban az A útválasztócsoporton keresztül 
menjenek ki a levelek, de baj esetére rendelkezésre áll a C cso- 


portban is egy SMTP-csatoló az Internet felé. A szervezeten be- 
lüli levélforgalomra pedig az jellemző, hogy B és C útválasztó- 
csoportból csak A-n keresztül mehetnek a levelek, kivéve, ha 
A-ban valami baj van. 


Első példa 


Tegyük fel, hogy C-ből szeretnénk B-be levelet küldeni. 
A C csoportban levő kiszolgáló megvizsgálja a lehetséges uta- 
kat: 
A Küldhetné rögtön B-nek, hiszen van csatoló, annak ára 
5 fitying. 
A Küldheti A-nak, majd B-nek két csatolón keresztül, 
melynek ára 1--1 azaz 2 fitying. 
A Tegyük fel, hogy mindegyik kapcsolat élő, és nincs kor- 
látozás egyiken sem. 
Az Exchange takarékos, a legolcsóbb utat fogja választani, te- 
hát az A csoporton keresztül fogja elküldeni a levelet B-nek, 
hisz az csak 2 fityingbe kerül, míg a másik 5 fitying. 


Második példa 
Most A-ból B-be szeretnénk üzenetet továbbítani, de az A és a 
B közti RGC A-B épp nem működik. 
Az A csoportban levő kiszolgáló a következő módon ,gondol- 
kodik": 
A Küldhetné a levelet közvetlenül B-nek, ez egyetlen fi- 
tyingbe kerül. 
A Küldhetné az üzenetet először C-nek, majd B-nek, ez 
1--5-6 fityingbe kerül. 
HA Megnézi a linkek állapotát, azt találja, hogy az RGC A- 
B csatoló nem működik, de nincs egyéb korlátozás a 
csatolókon. 
A megszerzett információk alapján csak egy irányba indíthatja 
az üzenetet, igaz hogy az drágább — 6 fitying —, de nincs mit 
tenni, C felé kell küldeni az üzenetet. Nincs más út. 


Harmadik példa 


B-ből szeretnénk az Interneten keresztül külső címre levelet 
küldeni. 
A B csoportban levő kiszolgáló a következő módon jár el: 

HA Küldhetné a levelet rögtön a saját SMTP-csatolóján ke- 
resztül, ez 10 fityingbe kerülne. 

A Küldhetné az A csoporton keresztül, mert ott is van 
SMTP-csatoló, ez 2 fityingbe kerülne. 

HA Küldhetné C csoporton keresztül A-ba, majd onnan az 
Internet felé, ez 7 fityingbe kerülne. 

HA Megnézi, mely csatolókon talál korlátozásokat és a 
Link State táblából megnézni, mindegyik csatorna mű- 
ködik-e. Tegyük fel, hogy minden rendben. 

Az Exchange megint csak az ár alapján dönt, az olcsóbb úton 
indítja el az üzenetet, vagyis az A csoporton keresztül megy ki 
az Internetre, mert az a legolcsóbb, 2 fityingbe kerül. 


Ez a módszer az OSPF útválasztáshoz hasonlít. Tanulság, hogy 
sokszor az útválasztás nem is olyan egyszerű, és ésszerűen be- 
állított csatolókkal hibatűrőbbé tudjuk tenni a levelezési szol- 
gáltatást. 


Folytatjuk... 


Dorner Csilla 
dorner.csillaonetacademia.net 
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Avagy nem minden arany, ami fénylik? 


x:..ellentétben a kriptográfiával, ahol a támadó észreveheti az üzenetet és módosíthatja azt, a sztega- 
nográfia célja, hogy a nyílt szöveget úgy rejtse el a gyanúmentes üzenetbe, hogy a támadó ne is lát- 
hassa meg, hogy a továbbított üzenet egy második üzenetet tartalmaz." 


Napjainkban egyre többször kerül szóba a titkosítás, mint a 
biztonságos üzenettovábbítás egyetlen módja. Ha valamit el 
akarunk rejteni a kíváncsi szemek elől: titkosítunk. De tényleg 
ez az egyetlen mód az információ védelmére? 


A szteganográfia 

Van egy másik módszer is a titkos üzenetváltásra, amikor nem 
titkosítunk, csak elrejtünk valamit valamibe. Az eljárás nem új- 
donság, különböző megvalósításait az ókoriak éppúgy hasz- 
nálták, mint a XX. század embere a II. Világháborúban. A gö- 
rög származású szteganográfia szó jelentése: rejtett írás. Ez a 
szó sok eljárást foglal magába, melyeket a védendő kommuni- 
káció során használhatunk, ilyenek például a láthatatlan tinta, 
mikroírás, betűk és szavak eltolásos elhelyezése és ismert kom- 
munikációs csatornák közé titkosak keverése és így tovább. 
Markus Kuhn 1995-ben ezt írta az eljárásról: ,A szteganográfia 
a kommunikáció művészete és tudománya, lehetőség magá- 
nak a kommunikációnak az elrejtésére. Ellentétben a kriptog- 
ráfiával, ahol a támadó észreveheti, feltörheti és módosíthatja 
az üzenetet, a szteganográfia célja, hogy a nyílt szöveget úgy 
rejtse el agyanúmentes üzenetbe, hogy a támadó ne is láthas- 
sa meg, hogy a továbbított üzenet egy második — esetleg titko- 
sított — üzenetet tartalmaz". Vagyis a titkosítás az üzenet értel- 
mét változatja meg, míg az adatrejtés az információcsere té- 
nyét igyekszik titkolni, elfedni. Ha nincs titkosításra utaló jel, a 
feltörés provokációja is kisebb. A szteganográfiát egyes (külö- 
nösen katonai) irodalmakban átviteli biztonságnak (transmissi- 
on security, TRANSEC) is nevezik. A magyar szóhasználatban 
a lényeget jól megmutató kifejezés, az adatrejtés (data hiding) 
terjedt el. 


Néhány legenda... 


Áttekintve a történeti emlékeken láthatjuk, hogy az információ 
elrejtésére számtalan módszert dolgoztak ki az idők folyamán. 
Az ókori Görögországban viasszal bevont táblákat használtak 
az írásra. Egy történet szerint, amikor Demeratus figyelmeztet- 
ni akarta Spártát, hogy Xerxész Görögország invázióját tervezi, 
lekaparta a viaszréteget, és üzenetét a csupasz fa rétegre írta 
fel. Ezután az egészet úgy vonta be ismét viasszal, hogy egyet- 
len ellenőrzés során sem derült fény a rejtett üzenetre. Egy má- 
sik, nem igazán emberbarát módszer volt, hogy egy megbízha- 
tó rabszolga fejét leborotválták és az üzenetet a csupasz 
fejbőrre tetoválták. Miután a küldönc haja ismét megnőtt, elin- 
dulhatott és az üzenet mindaddig láthatatlan maradt, amíg meg 
nem borotválták ismét. 
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A láthatatlan írás egyszerűbb és szokásos módszere volt a lát- 
hatatlan tinták használata, amely igen jól helyt álltak a II. Vi- 
lágháborúban is. Egy ártatlannak tűnő levél sorai között sok 
fontos információt rejthettek el így. A világháború korai szaka- 
szában az alkalmazott szteganográf módszerek köre szinte ki- 
zárólag a láthatatlan tinták használatára korlátozódott. Ezek ál- 
talában tej, ecet, gyümölcslevek felhasználásával készültek és 
közös jellemzőjük, hogy száradás után láthatatlanok lesznek, 
de melegítésre elsötétednek vagy egy másik anyaggal kezelve 
válnak láthatóvá. A technológia fejlődésével a láthatatlan tin- 
ták láthatóvá tétele egyre könnyebb lett, ezért sokan kísérletez- 
tek azzal, hogy egyre többféle kémiai anyag felhasználásával 
egyre biztonságosabb tintákat állítsanak elő. 

A kommunikációs csatornákon a sok titkosított üzenet között 
gyakran kódolatlan (null ciphers) szövegek is közlekedtek, de 
korántsem biztos, hogy minden az volt, aminek látszott. 
Az alábbi angol nyelvű szöveg egy időjárással kapcsolatos je- 
lentés: 





kapjuk: 





Ahogy egyre több módszert dolgoztak ki és alkalmaztak a tit- 
kos üzenetet váltani kívánók, a cenzorok egyre szélsőségesebb 
módon próbálták ellátni a feladatukat: tilos volt például olyan 
házhozszállítási megbízásokat postázni, amelyen (kézbesítési) 
időpont szerepelt, tilos volt keresztrejtvényeket, rejtvényeket és 
általában minden olyan dokumentumot postai úton elküldeni, 
ami titkos üzenetet tartalmazhatott. Ha a cenzor végképp nem 
tudott ,belekötni" egy levél vagy képeslap tartalmába, akkor 
összecserélgette a bélyegeket vagy a szavak sorrendjét, esetleg 
egyes szavakat más, rokon értelmű szavakkal helyettesített 
vagy éppenséggel újrafogalmazta az egész levelet. Minden új 
— az üzenet elrejtését célzó módszer — már meglévő eszközö- 
ket és ötleteket használt fel és alapvetően nem sokat változott. 
Az igazi újdonság az volt, amikor a régi módszer alapötletét öt- 
vözték egy újjal: az üzenetet változó vonalak, színek és egyéb 
képi elemek felhasználásával kódolták. 
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Szteganográfia ma 


Az elektronika, a digitális technika fejlődése új utat 
nyitott a szteganográfia számára, és ma is aktív kuta- 
tási területnek számít, főként a szerzői jogvédelem és 
a rejtett csatornák alkalmazásának és felderítésének 
területén. Talán már az eddigiekből is nyilvánvaló, hogy a 
módszer lényege nagyjából az, hogy nagy tömegű , lényegte- 
len" információ között elrejtjük a védeni kívánt üzenetet. 


Terminológia 


A továbbiak során azt, amibe beletesszük az információt hor- 
dozónak (cover, covertext) nevezzük, amit beleteszünk, azt 
egyszerűen üzenetnek (plaintext). Amit eredményül kapunk, 
az a stegotext. Hogy az üzenet nyílt szöveg vagy pedig rejtjel- 
zett, az eljárás szempontjából közömbös. A , digitális sztega- 
nográfia" legtöbbször a hordozó egyes bitjeinek, bitcsoportjai- 
nak a megváltoztatását jelenti, így mielőtt elkezdenénk az 
adatmanipulációt, egy feltételt el kell fogadnunk: csak olyan 
adat lehet hordozó, melynek értelmezésében nem okoz zavart, 
ha leírásához használt bájtok egyes bitjeit, bitcsoportjait, (pél- 
dául a legkisebb helyértékű bitjeit) megváltoztatjuk. Az adat 
feldolgozásának eredményében a megváltozott bitek általában 
egyfajta zajként jelennek meg: minél több bitet változtatunk 
meg, annál erősebben. Egy jó adatrejtő rendszerről is fel lehet 
tételezni, hogy a támadó - hasonlóan a titkosító rendszerekhez 
—-, a rendszer minden elemét ismeri, kivéve a feldolgozást eset- 
leg vezérlő titkos kulcsot. A továbbiakban ezt a tulajdonságot 
nem veszük figyelembe, de gyakorlati megvalósítás során erre 
emlékezzünk! 

Más rokon jellemző is van az adatrejtés és a titkosítás között: a 
lehetséges támadási módok. Az adatrejtés ellen irányuló táma- 
dásoknak a kommunikációs csatornák elleni támadásokhoz 
hasonlóan két fő módszere van: 

MA az adatrejtés elleni passzív támadásnak azt nevezzük, 
amikor a támadó felfedi az adatrejtés tényét, az elrejtett 
adatot esetleg megismeri, de nem változtatja meg vagy 
nem tudja megváltoztatni. 

MA az adatrejtés elleni aktív támadásnak nevezzük, ha a 
támadó az elrejtett adatot nemcsak megismeri, hanem 
azt megváltoztatni vagy eltávolítani is képes. 


Az adatrejtés célja 


Alapvetően két fő irányt különbözetünk meg az adatrejtési 
technikákban. Az egyik esetben nem kritikus a , rejtettség", vi- 
szont fontos, hogy az elhelyezett adat robosztusan, lehetőség 
szerint eltávolíthatatlanul kerüljön be a hordozóba. Ki kell áll- 
nia azt is, ha a stegotextet az általánosságban használt transz- 
formációknak vetik alá. A másik esetben nem annyira fontos a 
robosztusság, viszont garantálni kell a rejtettséget, az észrevét- 
len továbbítás lehetőségét. A gyakorlatban ezek mellé még egy 
jellemző társul: az elrejtendő adat mennyisége. Ahol az eltávo- 
líthatatlanság a fő követelmény, ott általában kevés adatot kell 
elhelyezni, ahol pedig a rejtettség, ott viszonylag sokat. Némi 
ellentmondás, hogy minél több adatot kell elrejteni, annál ke- 
vésbé valósítható meg a rejtettség. Az egyensúly az adott fel- 
adattól és alkalmazástól függ. A hordozó, mint adattovábbító 
csatorna kapacitását az az információmennyiség jellemzi, 
amely sikeresen átvihető és elő is állítható a vételi oldalon — 
felfedezés nélkül. 


Példa: Image steganography — adatrejtés képbe 
A mai digitális adattengerben igen sok lehetőség van arra, hogy 
elrejtsünk valamit valamiben: az ISDN csatornán folyó telefon- 
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beszélgetéstől és adatforgalmaktól kezdve a különböző hang, 
kép és videó-formátumokig, vagy szinte bárhol, ahol digitális 
adatok közlekednek. Igazán azok a digitális csatornák alkalma- 
sak, amelyek valamilyen emberi információt továbbítanak: 
hangot vagy képet, mert ezek — természetükből adódóan -— tar- 
talmaznak bizonyos redundanciát, látszólag felesleges adatot. 
Az ilyen ,hordozó-jelölteket" digitalizálással készítik, ennek 
lényege, hogy a továbbítandó hangot, fényerőt — vagy egyéb 
jelet — úgy alakítunk át, hogy elektromos úton mérhető legyen. 
Ezután bizonyos időközönként mintát veszünk a jelből, és az 
abban a pillanatban mért értéket digitális eszközökkel vala- 
hány biten ábrázoljuk (általában 8-24 
biten). És itt máris adódik egy le- 
hetőségünk az adatrejtésre! Ha 
ugyanis a számábrázolás a kettes 
számrendszer szabályainak megfe- 
lelően történik, a legkisebb helyértékű 
bitek esetleges megváltozása nem lesz 


Minél több adatot 


kell elrejteni, annál 


kevésbé valósítható jelentős hatással a rögzített jel re- 
ú ki konstruálására. Gyakorlatilag egy kis- 
meg a rejtettség. sé pontatlan mérésnek fog tűnni. Ter- 


me mészetesen nem szabad túl sok bitet 

módosítani, mert a változás előbb- 
utóbb akkora lesz, hogy az már zavaró és észrevehető. Telje- 
sen azonos elvek szerint helyezhetünk el információt digitali- 
zált fényképekben is, jóllehet azok készítésének folyamata 
kicsit más. A szteganográfia alkalmazásakor azonban mind- 
egy, hogy az adat honnan származik, csak az adatok felépíté- 
séről kell sok mindent tudnunk annak érdekében, hogy az ere- 
deti információ minél kisebb sérülést szenvedjen. Lássunk egy 
példát: 





E B-52-es bombázók a Davis-Monthan Air Force támasz- 
ponton 


Ki hinné, hogy a bal oldali dizájnos kép a jobb oldali légifel- 
vételt is tartalmazza? Erről a [B52] címen győződhetünk meg. 


Az adatokat általában valamilyen feldolgozás után küldik to- 
vább, ekkor még a feldolgozás előtt el kell rejtenünk az infor- 
mációt. Gondoljunk egy hangfelvételre: sok a szünet, a 
hosszabb-rövidebb csönd, vagy ha ránézünk egy fényképre 
igen sok, viszonylag homogén területet találhatunk rajta. A to- 
vábbításra alkalmas formátumok túlnyomó többsége eltünteti 
ezt a redundanciát (tehát tömörít) és olyan formába alakítja a 
digitalizálás közvetlen eredményeit, amelyek már emberi 
szemmel, füllel nem értelmezhetőek és többé-kevésbé érzéke- 
nyek az adatsérülésre is. A formátumtól függően elképzelhető, 
hogy még ekkor is van lehetőség adatmanipulációra, kihasz- 
nálva az adott formátum specialitásait (például kitöltőrészek, 
metainformációk, extension tags stb.). 


LSB módszer 1. 


A korábbi feltételeknek jellemzően megfelel a kódolatlan, true- 
color BMP formátumú képállomány. Ez a fájlformátum a képet 





úgy tárolja, hogy minden egyes mintavétel és mérés eredmé- 
nye tömörítés vagy más varázslat nélkül kerül az állományba. 
Gyakorlatilag a mérési eredmények szekvenciális halmaza. Ez 
a formátum megengedi a pixelek színmintáinak kismértékű 
megváltoztatását, amit az emberi szem csupán zajként érzékel. 
A változtatások a BMP formátumot nem teszik tönkre. Ha ke- 
vesebb bitet használunk fel a mintákból, a zaj kevésbé lesz 
észrevehető, ha többet, erősebb lesz. Általában nem alkalma- 
sak hordozónak a szövegfájlok, alfanumerikus adatokat tartal- 
mazó táblák, vektorizált térképek, tömörített vagy bináris állo- 
mányok. 

A fentiek figyelembevételével tekintsünk egy true-color 
1024x768 pixel méretű bitképet egyelőre tömörítés, fejléc és 
más formátum információ nélkül: 


HA Minden képpont leírására 3 bájtot használunk, ezek 
rendre a vörös, zöld, kék összetevőket tartalmazzák. 
A kép mérete ekkor: 1024x768x3x8 -— 

18 874 368 bit. (1I8Mbit, 2304Kb) 

HA Ha minden képpontból , ellopjuk" a legalsó bitet és he- 
lyére az üzenetet írjuk, a kép alapvetően nem változik 
meg, a színek megváltozását emberi szemmel nem le- 
het észrevenni. 

A Egy bit felhasználásával 1024x768x3x1 - 

2 359 296 bit (2.25Mbit, 288Kb) adatot tudunk elraktá- 
rozni a hordozó képbe, annak 12,599-át felhasználva. 

HA Lehetőség van arra is, hogy ne 1, hanem 2, 3 vagy 4 bi- 
tet ,csípjünk" le. Ekkor rendre 576Kb (2596), 864kb 
(37.596) vagy 1152Kb (5099) kapacitást biztosít a hor- 
dozó. Minél több bitet használunk el, annál nagyobb 
lesz a színek torzulása, amit előbb vagy utóbb már em- 
beri szemmel is észre lehet venni. 


Az ilyen nagyfelbontású, RGB színsémát alkalmazó, tömörítet- 
len képek egyik legnagyobb baja, hogy hatalmasak. A példá- 
ban szereplő kép fájlként legalább 2Mb, de még egy átlagos- 
nak mondható 640x480x3 tulajdonságokkal rendelkező kép is 
900Kb. Ha ilyen méretű állományt továbbítani akarunk, tömö- 
rítenünk kell. Ha magát a képfájlt, mint bináris állományt vesz- 
teségmentesen tömörítjük, elküldjük és a túlsó oldalon pedig 
kicsomagolják, semmi problémánk nincsen. Ha azonban a ké- 
pet már eleve valamilyen tömörített formátumban akarjuk tá- 
rolni, nem mindegy, hogy milyen formátumot választunk. Egy 
a lényeges, hogy ne veszteséges (például JPEG) formátumot vá- 
lasszunk, mert sajnos szembe kell néznünk az ilyen tömörítők 
sajátosságával: adatveszteség lép fel, ráadásul pont a legkisebb 
bitek helyén. Így tömörítéskor pont az az információ vész el, 
amit az előbb tuszkoltunk bele a hordozóba. Ezzel szemben 
nyugodtan használhatunk minden más olyan formátumot, 
amely ismeri a 24 bites színmélységet, emellett nem okoz adat- 
veszteséget (TIFF, PNG, JPEG2000). 

Főleg az internetes alkalmazásokhoz szívesen használják a 
256 szín kezelésére képes GIF formátumot. A formátum jó tö- 
mörítést biztosít a kisebb képekhez és viszonylag egyszerű a 
kódolása is. A gond csak az, hogy itt egy pixelérték csak köz- 
vetetten jelenti a pont színét: csak egy mutató a palettába, ahol 
végül majd eldől a pont színe. Tehát nem lehetünk biztosak 
benne, hogy ha megváltoztatunk egy 11110000. értékű pixelt 
mondjuk 111100017-re, akkor senki semmit nem fog észreven- 
ni, mert lehet, hogy az első érték fekete színre, a második ér- 
ték pedig fehérre mutatott. Csak akkor alkalmazhatjuk a már 
vázolt módszerünket, ha a palettában az egymást követő szí- 
nek hasonló RGB értékekkel rendelkeznek, vagy addig cserél- 
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getjük a pixelértékeket és a hozzájuk tartozó paletta- 
bejegyzéseket, amíg hasonlóak nem lesznek. Átme- 
neti megoldást jelenthet a palettaalapú színábrázolá- 


E 


sokban a szürkeskálás képek alkalmazása, ahol csak 5 
egy bájt ír le egy pixelt, de egy-két bitet itt is fel tu- 

dunk használni. E képeknél szinte kizárólag lineáris megfelel- 
tetés van a 0-255 pixelértékek és a fekete-fehér átmenet között. 


LSB módszer 2. 


A képek területén a BMP olyan, mint a hangfelvételek esetében 
a PCM formátumú hangfájl. Ez a fájlformátum a digitalizált 
hangot szintén a mérési eredmények időrendes, szekvenciális 
halmazaként tárolja. (Lényegében ugyanilyen az audio CD for- 
mátuma is, csak ott még különböző hibajavító kódok és tech- 
nikák is szolgálják a felhasználókat.) Ez a ,nyers" formátum 
megengedi a hangminták legkisebb helyértékű bitjeinek meg- 
változtatását, amit az emberi fül csupán zajként érzékel. A vál- 
toztatások a PCM formátumot nem teszik tönkre. Ha kevesebb 
bitet használunk fel a mintákból, a zaj kevésbé lesz észreve- 
hető, ha többet, a zaj erősebb lesz. A PCM kódolású hangfáj- 
lok meglepően sok kapacitást képesek biztosítani. Ha az alsó 
négy vagy akár nyolc(!) bitet felhasználjuk, a WAV fájl méreté- 
nek 2599 illetve 5090-a áll rendelkezésre, ami már több mega- 
bájt adat továbbítását is lehetővé teszi, például egy audio CD- 
n. Egy négyperces — átlagos hosszúságú — sztereó WAV 44,1 
kHz mintavételezéssel, 16 bites mintákkal 4x60x2x44100 -— 21 
168 000 mintát — 42 336 000 bájtot jelent. Ha itt elhasználunk 
4 bitet — a bátrabbak nyugodtan próbálkozhatnak akár 8 bittel 
is —, akkor 21 168 000 x 4 - 84 672 000 bit, azaz megköze- 
lítőleg 10 Mbájt információt tudunk elrejteni. 





elrejtendő adatfolyam 


hordozó adatfolyama 
































E LSB módszer: a hordozó kevésbé fontos bitjeit egysze- 
rűen kicseréljük ... 


Jóllehet az LSB módszer igen sok adat átvitelét teszi lehetővé 
(high payload), a módszer — ismertsége miatt — önmagában 
már nem alkalmas biztonságos adatrejtésre. 

Interneten általában nem is .wav, hanem MP3 fájlokat továbbí- 
tunk, azok erőteljes tömörítési aránya miatt. Arra is van le- 
hetőség, hogy MP3-ba rejtsünk adatokat [mp3stegol]. 


A kivétel erősíti a szabályt: szöveges állományok 


Az alapelvek tisztázásakor elfogadtuk, hogy csak olyan adat al- 
kalmas hordozónak, amelyik elviseli, ha egyes bitjeit megvál- 
toztatjuk. Azonban más szempont szerint is rejthetünk el infor- 
mációt. Ha azt mondjuk, hogy az alkalmas hordozónak, ami 
elviseli, hogy az adatok közé pótlólagos információt szúrunk 
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be, akkor lehet, hogy egy szöveges állomány is alkal- 
mas adatrejtésre. Írjuk fel a rejteni kívánt adatokat 
egyetlen bitfolyamként! Hordozónak válasszunk egy 
jó hosszú szöveget, például egy novellát! 
Végezzük el a feldolgozást a következőképpen: 
A hordozószöveget soronként olvassuk be. 
Ha a sor végén egy vagy több szóköz karakter találha- 
tó, töröljük ki mindet onnan. 
Ezután vegyük a rejteni kívánt bitfolyam következő — 
mondjuk -— három bitjét bináris számként. 
Ennek megfelelő mennyiségű szóközt szúrjunk a sor 
végére: ha például a bitek a 0112-310 számot adják ki, 
3 darab szóközt adunk a sorhoz. 
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Minél hosszabb bitcsoportokat használunk, minél több szó- 
közt szúrunk a sor végére, annál nagyobb a , lebukás" veszé- 
lye, de annál több információ tárolható egy adott szövegben. 
Minél kevesebbet, annál nagyobb a biztonság, de ezért cseré- 
be kevesebb a tárolásra használható hely. Számszerű példa: az 
A4 méretű oldalon átlag 55 sor van, ez az iménti 3 bitet felté- 
telezve 55x3-165 bit-20 bájt elrejtését teszi lehetővé oldalan- 
ként. Ez nem sok, de néhány módszer még ennyit sem képes 
elrejteni. Igaz, ezek másban jeleskednek, például az elrejtett 
információ nem változtatja meg a hordozó statisztikai jel- 
lemzőit, vagy éppen nagyon sok mindent képesek átvészelni. 
Más jellegű átalakításokkal is érhetünk el eredményeket. Ha 
megnézzük az olyan szöveges fájlokat, mint a HTML vagy az 
RTF formátum, egy kis ötlettel ott is rejthetünk el információt 
úgy, hogy a leírt dokumentum megjelenítésekor semmit nem 
veszünk észre. És nem csak arról van szó, hogy nem vesszük 
észre a változásokat, hanem hogy a megjelenített vagy ki- 
nyomtatott dokumentum, az eredetivel pontosan egyező lesz! 
Ugyanis mindkét formátumnak az a közös jellemzője, hogy 
olyan leírónyelvet használnak, amely angol szavakon vagy 
azok rövidítésein alapul, és a dokumentum fizikailag tiszta, 
hétbites ASCII formátumban leírható. Mindkét nyelvben egyér- 
telműen elkülöníthetők a formázáshoz használt kulcsszavak a 
dokumentum szövegétől vagy egyéb objektumától: a HTML- 
ben , c" és ,2" jelek, a RTF-ben ,(" és ,)" jelek határolják őket. 
Egyik formátum sem érzékeny arra, hogy ezek a határolt egy- 
ségek kis- vagy nagybetűvel vagy éppen vegyesen vannak írva. 
Ezért akárhogy írhatjuk őket: ahol egy ,1"7-es bitet akarunk je- 
lezni, oda nagybetűt írunk, ahol ,0" a kérdéses bit, oda kisbe- 
tűt. Így például a , HTmL5" tag egy 11012 bitsorozatot képvi- 
selhet. Sajnos nem egészen ilyen egyszerű a helyzet, mert a 
HTML-ben Javascript is lehet, ami viszont érzékeny a kis és 
nagybetűk közötti különbségre. Hasonlóan nem írhatjuk át az 
,£img2" , a ,cformo", a ,2dink:" és ,ca:" tagok fájlhivatkozá- 
sait sem, mert az UNIX-os szerver esetén katasztrofális lehet. A 
korlátokat figyelembe véve viszont szabadon garázdálkodha- 
tunk. Ismereteim szerint RTF-ben hasonló korlátozások nincse- 
nek, csak a fájl első hat karakterének kell ,(rtf1)"-nek lennie 
(kisbetűvel). Az eljárás során a hordozó mérete nem változik 
meg. 


Szimmetrikus és aszimmetrikus adatrejtés 


Az eddig bemutatott szteganográf eljárásoknál nincs szükség 
az eredeti hordozóra az elrejtett adat kinyeréséhez, mert anél- 
kül is dekódolható az elrejtett adat, így azt nem kell továbbíta- 
ni, vagy előzetesen egyeztetni. Ezeket az eljárásokat vak eljá- 
rásoknak nevezzük (blindly methods) és a jelenleg használt 
technikák döntő többsége ilyen. 
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stegosystem 


Egy egyszerű példa a másik megoldásra: az elrejtendő adatbi- 
teket egy képben úgy helyezzük el, hogy az egyes biteket vala- 
milyen szabályszerűség szerint az eredeti kép fölé ,terítjük", 
majd az eredeti pixelértékekhez hozzáadjuk (valamelyik szín- 
csatornához, de akár mindháromhoz egyszerre). A létrejövő 
színingadozás egy részletdús képnél senkinek sem fog feltűnni. 
Az ilyen eljárásokat letételjárásoknak nevezzük (cover escrow). 
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E Cover escrow rendszer 


Jóllehet ez utóbbi eljárások biztonságosabbak, azonban a gya- 
korlati megvalósítás során jelentős problémát okozhat az ere- 
deti hordozó eljuttatása a címzetthez, vagyis ugyanazok a 
problémák jelentkeznek ismét, amelyek a szimmetrikus titkosí- 
tó algoritmusok kulcscsere problémáját is jellemzik. 















































Interperceptile watermarking 
Rejtett vizjel 


Visible watermarking 
Látható vízjel 

















E Információrejtési technikák a felhasználás célja szerint 





Alkalmazási területek 


A fenti ábra a főbb technikák csoportosítását mutatja, melyek 
más-más felhasználási területhez tartoznak, és különböző a 
megvalósítandó céljuk is. A következőkben ilyen szempont 
szerint ejtünk néhány szót az egyes megoldási lehetőségekről. 


Copyright watermarking 


A szteganográfia egyik gyakori felhasználása az elektronikus 
úton terjesztett publikációk védelme, az elektronikus vízjel- 
vagy ujjlenyomat alkalmazása. A grafikával foglalkozók egy- 
egy elkészült képükbe például az Adobe Photoshop használa- 
tával tudnak egyedi azonosítót tenni. De hasonlóan lehetne 
minden audio CD sávba is copyright információt rejteni. Akár 
képről, akár hangról van szó, a módszer biztosítja, hogy az 
azonosító minden másolatban benne lesz, onnan gyakorlatilag 
eltávolíthatatlan. Ha copyright jelzésként nem szöveget vagy 
számot helyezünk el, hanem képet, emblémát vagy hangot (te- 
hát olyan üzeneteket, melyek egyébként is redundánsak így 
,sok mindent kibírnak"), valószínű, hogy még különböző szű- 
rések, ,belerajzolások" után is megmarad a készítő eredeti (hez 
hasonló) azonosítója. Érdemes megemlíteni azt is, hogy ha a 
hamisító saját ,védjegyet" tesz a ,művére", az nem fogja az 
eredetit felülírni, hanem mindkettő megmarad (főként ha kü- 
lönböző módon, különböző helyekre teszik azonosítójukat). 
Az ilyen jellegű védelmek másik fajtáját, az elektronikus ujjle- 
nyomatot (fingerprint) másra használják. Ennek feladata egy- 
egy másolat útjának nyomon követése, ugyanis az ujjlenyomat 
egy olyan egyedi azonosító, melyet minden egyes jogszerű 
másolatba elhelyeznek. Ha később egy illegális másolat fel- 
bukkan, a szerzői jog tulajdonosa az ujjlenyomat dekódolásá- 
val azonosíthatja az eredeti másolat tulajdonosát (traitor-tra- 
cing, áruló-követés). A vízjelek között tehát két fő feladat osz- 
lik meg: 


1. Fragile watermarking — ,törékeny vízjel": Feladata, hogy 
biztosítsa a legkisebb módosítás észrevételét is, mihama- 
rabb felfedve így a hamisításokat, változtatásokat. 

2. Robust watermarking — , strapabíró vízjel": Feladata, hogy 
túlélje a módosításokat, a lehető legtovább megmaradva 
bizonyítsa a megjelölt hordozó eredetét. 


Covert channels 


Az adatrejtés támogathatja az ún. észlelhetetlen csatorna (hid- 
den channel, covert channel) megvalósítását, illetve biztonsá- 
gi szempontból felveti ezek keresésének szükségességét. A 
kommunikáló felek az észlelhetetlen csatorna segítségével kie- 
gészítő információkat küldhetnek egymásnak, például jelezhe- 
ti a küldő a címzettnek, ha az adott dokumentumot egy kény- 
szerítő harmadik fél hatására írta alá. A legfontosabb következ- 
ménye a csatorna létének azonban az, hogy egy ilyen eljárást 
implementáló programozónak, hardver-gyártónak lehetősége 
van arra, hogy az észlelhetetlen csatorna segítségével olyan in- 
formációkat juttasson ki egy rendszerből, amelyeket nem len- 
ne szabad (például egy kulcspár titkos kulcsát, jelszavakat vagy 
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más érzékeny adatokat). Informatikai rendszerek biz- 
tonsági vizsgálatánál ezért az egyik legfontosabb 
szempont az észlelhetetlen csatornák keresése és 


1 E 
megszüntetése. 


Steganography 

Az ábra harmadik főcsoportja azokat a módszereket takarja, 
amelyekről a cikk eddig is szólt. Ez nem más, mint adatrejtés 
tömeges adatátviteli célzattal, a kriptográfia alternatívájaként 
vagy azt kiegészítő módszerként. Ne feledjük, az adatátviteli 
szteganográfia fő célja, hogy úgy rejtse el az üzenetet, hogy a 
lehetséges támadó észre se vegye az üzenetküldés tényét, 
csökkentve így annak az esélyét, hogy egyáltalán megpróbálja 
dekódolni, feltörni az üzenetet. Más szavakkal ez azt jelenti, 
hogy az üzenet küldése nem provokálja az üzenet feltörését. 


Titkosító módszerek vs adatrejtés 


A szteganográfiai eljárásoknak rengeteg megvalósítása lehetsé- 
ges és az eljárás nem csak digitális feldolgozásban használha- 
tó, hanem egyéb médiákon is megvalósítható. A szteganográfi- 
ának helye van a titkosító rendszerek között, jóllehet azokat 
nem válthatja fel, de megvalósíthatja azok célkitűzéseinek egy 
részét. 

Előnye a kriptográf módszerekkel szemben, hogy a továbbított 
üzenetnek kisebb esélye van arra, hogy a kódtörő egyáltalán 
észreveszi. Bár ha egy feltételezetten titkosított kommunikáci- 
óban a felek csak képeket küldözgetnek egymásnak, az elég 
gyanús lehet. Ilyenkor célszerű a különböző módszereket ke- 
verni, vagy a csatornán valódi titkosított, de tartalom nélküli 
üzeneteket is küldeni. 

Való világ 

Néhány olvasó, aki a cikket megjelenése előtt olvasta, feltette 
azt a gyakorlatias kérdést, hogy a bankók vízjelét, zárjegyeket 
hova sorolnám? Nos, a zárjegy egyértelműen , törékeny vízjel". 
A bankók vízjele robosztus vízjel, és a papír eredetét igyekszik 
bizonyítani. Az egyéb ismérvek (UV reagens szöszök, holog- 
ram csik, stb.) pedig a törékeny vízjelekhez tartozhatnak. Álta- 
lában a legtöbb elhelyezett védjegy (itt most nem a márkane- 
vekre gondolok) törékeny — így akadályozva meg az újrahasz- 
nosítást — és egyúttal az eredetiséget is igazolják. 

Az egyértelmű megkülönböztetés vagy besorolás nehéz, mert 
legalább két fontos különbség van a fizikai formában megje- 
lenő értékek és a fentebb tárgyalt technikák között: 


1. Az elektronikus dokumentumoknál lényegtelen, hogy mi- 
lyen fizikai formában tárolódnak. Egy bankónál viszont na- 
gyon is fontos, hogy milyen papírból készült. 

2. A bankóhamisítás során a különböző ismertető jegyek el- 
helyezése a cél (bizonygatva, hogy a bankót az állam ké- 
szítette), és nem azok eltávolítása (eredet letagadása). 


Virasztó Tamás 
wachergwestel900.net 
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1-1 Portál Paraldigmal 


Avagy mit tegyünk, ha sürgősen 
portált kell építenünk? 


Ha főnökeink vagy ügyfeleink azt várják tőlünk, hogy integráljunk egy-két tucat különböző alkalma- 
zást úgy, hogy az információk és szolgáltatások az Interneten is elérhetők legyenek, mindezt egyszerű 
legyen kezelni, és persze az egész minimális költségvetésből és tegnapra kell, akkor bizony nehéz dol- 
gunk van. Az ma már nem kérdés, hogy ilyenkor vállalati portált kell építeni, de hogy milyen eszkö- 
zökkel, milyen architektúrával és milyen platformon, az már nem olyan egyértelmű. Jön a portál para. 


Immár majdnem öt éve foglalkozom portálfejlesztéssel Micro- 
soft platformon, és úgy érzem ez az üzletileg igen fontos téma 
méltatlanul kevés helyet kap a magyar szakirodalomban. Ezt a 
hiányosságot pótolandó kezdtem megírni ezt a cikket, amely 
terveim szerint egy cikksorozat első, bevezető része. 

Mivel a vállalati portál egy erősen üzletorientált IT megoldás, 
nem hagyhatom ki cikkemből annak üzleti vonatkozásait. An- 
nál inkább nem, mert a portálprojektek nagy része sajnálatos 
módon pont azért bukik meg, mert az üzleti és IT célok nem 
találkoznak. Az IT ugyanis nem mindig érti, mit kíván a me- 
nedzsment, az üzleti vezetők pedig nem ismerik a lehetősége- 
ket, és még ha meg is kérdeznek minket, nem értik mit zagy- 
válunk mi műszakiak. 

Ebben a megoldhatatlannak látszó helyzetben azonban ne- 
künk (műszakiaknak) van szerencsénk, ugyanis sokkal 
könnyebb némi , közgáz"-t tanulnunk, mint egy átlagos mene- 
dzsernek megérteni, miért hagyta ki a Microsoft a Ctt-ból a 
többszörös öröklődést. 

Ebben az első cikkben szeretnék tehát némi üzleti szemléletet 
is átadni, de megpróbálom mindezt nem a műszaki részletek 
terhére tenni. A soron következő cikkek az itt felvetett témák 
műszaki részleteit fogják alaposabban kivesézni. 


Üzleti probléma 


A nagyobb szervezetek rendelkeznek különféle üzleti szoftve- 
rekkel, illetve a gyorsan változó üzleti környezethez újabbak 
fejlesztése, vásárlása szükséges. A meglévő szoftverek egy ré- 
sze modern, egy része régebben vásárolt vagy házilag fejlesz- 
tett, de a leggyakrabban előforduló probléma az, hogy nem in- 
tegráltak, sok esetben ugyanazokat az adatokat tartalmazzák 
redundánsan, nemegyszer inkonzisztensen. 

Ebből következik, hogy ahhoz, hogy a felhasználó komolyabb 
üzleti összefüggéseket találjon, sőt néha ahhoz is, hogy egy- 
szerű információkhoz férjen hozzá, több alkalmazást, több kü- 
lönböző szoftvert kell futtatnia egymás mellett vagy egymás 
után. Ez általában ablakok kavalkádját eredményezi, és inkább 
hátráltatja, mint segíti az információszerzést. A probléma igen 
általános, szinte minden szervezetet, vállalatot érint. 

A különféle alkalmazások átírása oly módon, hogy azok egy 
rendszerként működjenek igen nehéz és hosszadalmas feladat, 
és gyakran nem műszaki, hanem gazdasági, jogi akadályokba 
vagy szervezeti ellenállásba ütközik. Az effajta integrációs pró- 
bálkozások igen ritkán gazdaságosak. Tovább nehezítheti a 
megoldandó feladatot az, hogy ennek ellenére általában futnak 
kisebb-nagyobb integrációs projektek, amik ritkán sikeresek, 
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de annál inkább csökkentik az IT megoldások iránti bizalmat a 
menedzsment köreiben. Éppen ezért fontos, hogy amennyiben 
portál építésbe kezdünk, pontosan ismerjük, miféle fába vág- 
juk a fejszénket. 


Mi az a portál? 

Évekkel ezelőtt az Internet elterjedésével elindultak az első 
olyan honlapok, melyek egy adott közösséggel vagy témakör- 
rel kapcsolatos információkat gyűjtötték egy helyre. Az efféle 
honlapok nem maguk kínálták az in- 
formációt és szolgáltatásokat, hanem 
,csak" hivatkozásokat adtak az egyes 


... ebből a meg forrásokhoz; gyakran nem is voltak 
többek tematikus linkgyűjtemények- 
közelítésből hasznot nél. Az ilyen honlapok belépőpont- 
ként, kapuként szolgáltak a releváns 
lehet húzni adatok hatalmas halmazához, innen 


ered a portál, azaz kapu elnevezés. 
Xi A portálok ugyanakkor saját maguk is 
nyújtottak szolgáltatásokat, amelyet egyetlen hivatkozott forrás 
sem nyújtott önmagában, ezáltal a portál további értéket te- 
remtett. A kategorizálás vagy a keresőszolgáltatás minden por- 
tál alapszolgáltatásai közé tartozik, célja az információk célba- 
juttatásának felgyorsítása, ezáltal az információra éhes személy 
üzleti előnyhöz juttatása. 
A gazdálkodó szervezetek vagy cégek hamar rájöttek, hogy 
ebből a megközelítésből hasznot lehet húzni, és az Internetes 
portálokhoz hasonlóan a céges Intraneten is elkezdtek portálo- 
kat építeni. Az így kialakult vállalati portálok kezdetben Inter- 
netes társaikhoz hasonlóan egyszerű HTML oldalak voltak, 
egy-két alapszolgáltatással kiegészítve. 
Napjainkban a vállalati portálmegoldások nem próbálják meg 
a lehetetlent, nem próbálják az alkalmazásokat teljes mérték- 
ben integrálni, csak az alkalmazásokból kinyerhető információ 
megjelenését és a fontosabb alkalmazásfunkciókat teszik egy 
képernyőre, pontosabban egy weboldalra. A különféle portál- 
szoftverek képesek arra, hogy egy weboldalként, egy bön- 
gészőablakban jelenítsenek meg több forrásból jövő adatokat 
vagy felhasználói felületeket. Ez az egy képernyő így kaput nyit 
a szervezet különféle szoftverrendszereiben tárolt információi- 
hoz, más szóval információs Vállalati Portált valósít meg. 


Internet -— Intranet — Extranet 


Egy szervezet üzleti folyamataiban sokan vesznek részt. Házon 
belül a cég alkalmazottai, dolgozók, menedzserek, vezetők és 
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információ melyik rendszerünkből érkezik, és a 
funkció melyik alkalmazásból érhető el. Ez a megol- 
dás a felvétel-elbocsátás körüli problémákat is meg- 


tulajdonosok, házon kívül pedig a nagyközönség, az állami és 
önkormányzati szervek, vásárlók, megrendelők, partnerek és 
beszállítók. A szervezet hatékony működéséhez elengedhetet- 





len, hogy ezek a csoportok hozzáférjenek a nekik szükséges in- 
formációhoz és szolgáltatásokhoz, illetve képesek legyenek a 
szervezet számára fontos információt közölni, a rendszerbe 
juttatni. Az is fontos, hogy a szervezet irányítani és felügyelni 
tudja, hogy a megfelelő információ a megfelelő irányba terjed- 
jen, ne kerüljön illetéktelen kezekbe, viszont eljusson azok- 
hoz, akiknek igazán szükségük van rá. 

Az Internetportál jól ismert megoldás a nagyközönség tájékoz- 
tatására, de a portálmegoldás igazi előnye, hogy nem csak a 
nagyközönséget tudja információval ellátni az Interneten ke- 
resztül, hanem saját munkatársait is egy belső hálózaton, az 
Intraneten keresztül. Az Intranet nem más, mint egy a szerve- 
zeten belül működő, az Internet technológiáit hasznosító há- 
lózati rendszer, egy privát, mini Internet. Az Intranet könnye- 
dén kiterjeszthető a szervezeten kívülre is, így az információ- 
áramlás a szervezet határain kívül is folyhat, de korlátozott és 
a szervezet által felügyelt módon. A szervezet határain túlmu- 
tató, de a nagyközönségtől elzárt hálózatot extranetnek ne- 
vezzük. 

Nemzetközi kutatócégek legfrissebb felmérései szerint a cé- 
gék olyan megoldásokat keresnek, amelyek mindhárom meg- 
oldást egy közös infrastruktúrán képesek ellátni, jelentősen 
csökkentve a beruházási és üzemeltetési költségeket. Mene- 
dzser kollégáink ezt úgy mondják, hogy a modern portálnak 
nagyobb a ROLI-ja és kevesebb a TCO. A ROI az angol Return 
on Investment, azaz megtérülés, a TCO a Total Cost of 
Ownership, azaz teljes üzemeltetési költség kifejezést takarja. 
Beszerzéskor alaposan el kell gondolkodni, hogy a közeli és 
távoli jövőben miként kívánja a szervezet kihasználni a por- 
táltechnológia adta kommunikációs csatornákat. Ha tehát a 
feladat Internetportál készítése, érdemes előre tekinteni, és fel- 
hívni a menedzsment figyelmét, hogy ha most megfelelő 
szoftvert vásárolnak, később alacsony költséggel intranetet 
vagy extranetet is tudunk majd építeni. Fordítva is igaz, intra- 
netépítés esetén is akad olyan információ, amit a cég webol- 
dalán érdemes a nagyközönséggel megosztani, és később 
esetleg extranet portált is létrehozni ügyfeleknek vagy beszál- 
lítóknak. 


Single Sign-On (Egy jelszó mind felett) 


A jó vállalti portál megoldást adhat egy másik, az alkalmazás- 
integrációval kapcsolatos problémára, a jelszavak kezelésére. 
Általános probléma, hogy ahány szoftver üzemel a szervezet- 
ben, annyi felhasználónév és jelszó párt kell megjegyezni, és 
ha az egyik rendszerben megváltozik, vagy törlődik a jelszó, 
nincs olyan ember, aki kényelmesen eligazodna a jelszavak 
kavalkádjában. Sok helyen ez akkor is így van, ha már van Ac- 
tive Directory, hisz nem minden alkalmazás ,tudja" az AD-t, 
és nem is mindet lehet átalakítani. Új munkatársak felvitele és 
törlése is komoly gondot tud okozni. Gyakori, hogy az új kol- 
léga első heteit jelszavak utáni rohangálással tölti munka he- 
lyett, illetve régen elbocsátott kollégák még mindig rendelkez- 
nek hozzáféréssel kulcsfontosságú adatokhoz. Egyes kutatá- 
sok szerint a nagyvállalati betörések (hackelés) hátterében az 
esetek többségében bosszúra éhes, elbocsátott munkatárs se- 
gítsége áll. Erre a problémakörre nyújt megoldást a portál egy- 
jelszavas megoldása, angolul Single Sign-On (SSO). A portál- 
ra bejelentkezéshez csak egy jelszóra van szükségünk, ezzel 
hozzáférést nyerünk minden olyan információhoz és funkció- 
hoz, amit a portál prezentál nekünk, függetlenül attól, hogy az 
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oldja, mert elég egy jelszót kiadni, vagy visszavonni. 
Ez a problémakör biztosan egy önálló cikket kíván, 
elöljáróban azonban kitérek egy fontos dologra a portálokkal 
kapcsolatban. Nem szabad, hogy az egységes megjelenésű 
portál GUI-tól várjuk az SSO-hoz hasonló kihívások megoldá- 
sát. Az ilyen esetekben ugyanis nem elég a felhasználói felüle- 
tet, a prezentációt kiépíteni és egysé- 
gesíteni, hanem mögöttes üzleti logi- 
kát is kell alkotni. 


A statikus 


Azok a portálgyártók, akik azt hirde- 
tik, hogy termékeik megoldják az SSO 
ATIML generálásáról és hasonló problémákat, nem mindig 
teszik hozzá, hogy ez jelentős szerve- 
érdemes zési munkát is igényel, ugyanis a sok 
rendszer között igen komplikált mó- 
elfeledkezni. don kell szinkronizálni a felhasználók 


azonosítóit, és ez egyedi integráció 

nélkül nem oldható meg; a portál- 
szoftverek csak eszközökkel támogatják a munkát. Aki végzett 
már AD-bevezetést, tudja, hogy legtöbbször nem a telepítés, 
hanem a felhasználók adatainak összeszedése az igazi kihívás; 
így van ez egy komolyabb SSO-háttérlogika felépítésénél is. 
Szerencsére vannak olyan kész szoftverek, mint a Microsoft 
Metadirectory Services, melyek a dobozból kivéve, külön fej- 
lesztés nélkül is sok problémát megoldanak. 


Dinamikus oldalak 


A modern portálmegoldások a weboldalakat alkotó HTML-t 
mindig a letöltés pillanatában állítják elő valamilyen adatfor- 
rásból, adatbázisból vagy alkalmazásból. Ez még akkor is így 
van, ha az URL látszólag statikus HTML-re mutat. Ez a folya- 
mat kicsit időigényesebb, mint egy egyszerű, előre megírt, más 
néven statikus HTML oldal letöltése, hiszen a HTML-t itt egy 
program állítja elő, ráadásul minden látogatónak egyedileg. A 
portáloldalak általában kicsi ,dobozkákból" állnak, amelyek 
mind egy-egy alkalmazást képviselnek a GUI-ban. Ezek a web- 
partok, portletek, gadgetek, vagy placeholderek ráadásul több 
forrásból egyszerre, de egymástól függetlenül generálódnak, 
ezért az ASP.NET megoldásoknál is lassabb futást kell feltéte- 
lezni. A portáloldalak felépítése eltér egy ASP-oldalétól, hiszen 
az egyes dobozkák mögötti kód más-más gyártó műve is lehet, 
melyeket forráskódszinten nem lehet egybeépíteni, ráadásul a 
felhasználók is képesek rakosgatni őket (testreszabáskor). Az 
egy oldalra felpakolt dobozkák tartalma tehát minden letöltés- 
kor személye szabottan kerül előállításra, ami a portál legna- 
gyobb előnye. Ha viszont több ezer látogató használja a por- 
tált, és az oldal nagy része nem változik, a portál motor ugyan- 
azt a feladatot (pl. kigyűjteni a legfrissebb híreket) sok ezerszer 
végzi el, ugyanúgy. Ez fölöslegesen terheli a szervereket, ami 
nem megengedhető. A statikus HTML generálásáról pedig ér- 
demes elfeledkezni, mert egy közepes portál esetében is iszo- 
nyú kínszenvedést okozhat egy apró menedzseri igény ,bere- 
szelése" a HTML generátorba. 


Cache 


Az átmeneti tár, angolul cache -— az előző példánál maradva — 
a kigyűjtött híreket egy rövid ideig tárolja, így nem kell a szer- 
vereknek fölösleges munkát végezniük. Fontos, hogy olyan 
portálmotort és fejlesztőeszközt válasszunk, ami képes a do- 
bozkák tartalmát egyenként cacheelni. Így az oldalon elhelye- 


ta EA ER Z ETT. §G 


- (RMÓIP]JRIRg IRIIOd / 


éyünyajtda [lay pIRmiod nasobins ey "yunfbay tu ha6eny 


31 





. Avagy mit tegyünk, ha sürgősen portált kell építenünk? ? DP UP 


Portál Paraldigmal 


37 


zett dobozkák egy része mindig teljesen friss és sze- 
mélyre szabott lehet, az olyan adatok, melyek ritkáb- 
ban változnak, viszont bemennek az átmeneti tárba, 
és onnan kerülnek kiszolgálásra. Ha az oldalunkat 
percenként több ezren nézik, egyperces átmeneti tá- 
rolás is több ezer adatbázis-lekérdezéstől mentesíti a szerver- 
rendszert, így jelentős összegeket lehet a hardverbeszerzésnél 
vagy a fejlesztésnél megtakarítani. 

Tudom, ez eretriekségnek hangzik, de a jó cachefunkció le- 
hetőséget ad arra, hogy a portálunk egyes részeit ne kelljen ,,ki- 
optimalizálni". (Ez olyan projekteknél lehet igen hasznos, ahol 
vészesen közeleg, vagy már rég lejárt a határidő.) A menedzs- 
ment sokkal elégedettebb lesz egy olyan portállal, ami néha — 
amikor lejár a cache — lassú, de egyébként határidőre elkészül 
és működik. Ekkor már könnyebben kapunk időt a gyorsításra. 
A .Net framework cache támogatása és annak megfelelő hasz- 
nálata szintén egy tervezett cikk témája. 


Skálázhatóság 

Ha a szerverek az átmeneti tárolással sem tudják kiszolgálni a 
megnövekedett látogatószámot, a rendszert bővíteni kell. Az 
olyan rendszert, ami könnyen és alacsony költségen bővíthető, 
jól skálázhatónak nevezzük. Figyeljünk oda, mert menedzser 
kollégáink nem mindig tudják mit jelent ez a kifejezés, és gyak- 
ran összekeverik a skálázhatóságot (scalability) a teljesít- 
ménnyel (performance). A skálázhatóság nem azt jelenti, hogy 
a rendszerünk gyorsabb lesz, csak azt, hogy több felhasználót 
tud lassulás nélkül kiszolgálni. 

A .Net környezetben épített rendszerek, ha jól vannak kitalál- 
va, igen jól skálázhatók, nem kell mást tenni, mint egy-egy új 
szervert vásárolni, telepíteni a szoftvert, csatlakoztatni a közös 
adatbázishoz és az új szerver máris futásra kész. A meglévő 
szerverekhez pedig nem is kell hozzányúlni. Az ilyen skáláz- 
ható megoldást hálózati terheléselosztásos megoldásnak ne- 
vezzük, hiszen a hálózaton keresztül bejövő lekérdezések so- 
kasága, a terhelés, megoszlik több szerver között. 

A több webszerverrel működő rendszereket web farmnak is 
szokás hívni. A Windows 2000 Advanced Serveren futó portál 
akár 24 szerverig is kibővíthető, így a legnagyobb országos In- 
ternetes vagy Intranetes portálok terhelésének többszörösét is 
ki tudja szolgálni, persze ehhez a mögé rakott adatbázist is tu- 
ningolni kell némiképpen. A Windows 2000 Advanced Server 
operációs rendszernek köszönhetően a terheléselosztás (NLBS 
—- Network Load Balancing System) külön költséges hardver 
megvásárlása nélkül megoldható. 


Nagy rendelkezésre állás 


Az NLBS terheléselosztás másik nagy előnye, hogy a több 
szerver megléte redundanciát visz a rendszerbe. Ha a több 
webszerver közül az egyik meghibásodik, a többi még vígan 
működik, és átveszi a kiesett gép terhelését. Az NLBS megol- 
dással tehát több legyet ütünk egy csapásra: skálázható lesz a 
rendszerünk, megnő a rendelkezésre állás, és egyszerűbb lesz 
az üzemeltetés, hiszen a karbantartást, ha egyszerre csak egy 
szervert állítunk le, több ideig lehet végezni, anélkül, hogy a 
szolgáltatás megállna. 

Az SPF (Single Point of Failure) egy ilyen webfarmon általában 
az adatbázisszerver — amit a portálszoftver használ —, illetve 
maguk a hálózati eszközök, switchek, routerek és tűzfalak. A 
megfelelő hardver kiválasztásával a Microsoft SOL 2000 Ser- 
ver is megduplázható, de ez komoly költségnövekedéssel jár. 
Hiába redundáns a portálunk, ha a mögötte lévő rendszerek 
állandóan meghalnak. 
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Tartalommenedzsment — CMS 


A portál oldalain megjelenő információk egy része valamilyen 
alkalmazásból származik, de nagy többségük egyszerű szöve- 
ges vagy képi információ, főleg Internetportálok esetében hét- 
köznapi webes tartalom. A portálokon szereplő hírek, cikkek, 
leírások vagy egyéb képekkel illusztrált szöveges írásművek 
összefoglaló neve: tartalom. A portál tartalmát előállíthatja 
egy szerkesztőség vagy a szervezet különféle területein dolgo- 
zó alkalmazottak saját maguk. Kívánatos cél, hogy a webes 

tartalmat az tegye föl a portálra, aki 


zi azt előállítja. Ha PR- vagy marketing- 
szöveg, a kommunikációs osztály, ha 

Ha az oldalunkat DEI műszaki leírás, a support, ha 

szerződésminta akkor a jogászok. A 

cenként több ezren portálon futó tartalommenedzsment 


(angolul . Content . Management 
System, CMS) alkalmazás segítségé- 
vel a tartalmat előállítók önállóan is 
meneti tárolás is több . könnyedén készíthetnek és publikál- 
hatnak tartalmi elemeket az Interne- 
ten, Intraneten vagy Extraneten. 

A jó CMS rendszer garantálja, hogy a 


nézik, egyperces át- 


ezer adatbázis-lekér- 


dezéstől mentesíti tartalmi elemek mindig a megfelelő 
helyen, a megfelelő időben és megfe- 
a szerverrendszert. lelő kinézettel jelenjenek meg, illetve 


igény szerint gondoskodik a megje- 
lenő tartalom megjelenés előtti szer- 
kesztői, vezetői jóváhagyásáról. A CMS minden modern por- 
tálszoítver része kell legyen, sőt gyakori, hogy vállalati portál 
projektek CMS bevezetésből , nőnek ki". 


Kereső 


Minden portál legfontosabb feladata az, hogy a felhasználót a 
lehető leggyorsabban és legegyszerűbben információval lássa 
el. Mivel a legtöbb portálon naponta több tucat hír, cikk, do- 
kumentum vagy egyéb írásmű keletkezik (nem beszélve az al- 
kalmazásokban tároltakról), az információtengerben való ke- 
resésre szoftvermegoldást kell alkalmazni. Fontos, hogy portá- 
lunk képes legyen a tartalomban szabad szöveges kereséseket 
futtatni. Mivel a keresési igények igen változatosak és kiterjed- 
hetnek más rendszerekre (fájlszerverek, levelezőszerverek, 
dokumentumkezelő szoftverek, más alkalmazások, az Inter: 
net) is, olyan portálmegoldást érdemes választani, amely ren- 
delkezik a megfelelő interfésszel, API-val, hogy a nekünk és 
menedzsmentünknek tetsző keresőmegoldást ki tudjuk fej- 
leszteni, anélkül, hogy az egész keresőt újra kellene írni, vagy 
a beépített keresőt kellene úgy elfogadnunk, ahogy azt kapjuk. 


Csoportmunka támogatás 


A legtöbb cég vagy szervezet munkatársai csoportokban dol- 
goznak, így a csoport hatékonysága nemcsak attól függ, hogy 
abban az egyes munkatársak milyen hatékonyan dolgoznak, 
hanem attól is, milyen hatékonyan tudnak összedolgozni. A 
portál erre is adhat megoldást, ha olyan alkalmazásokat telepí- 
tünk rá, amelyek támogatják a csoportmunkát. 

Az ilyen szoftvereket csoportmunka-támogató, angolul group- 
ware vagy collaboration néven emlegetik. Kétféle megoldás 
létezik, az egyik, amikor egyszerű funkciókat a portálon mini- 
alkalmazásként valósítanak meg, a másik, amikor egy csoport- 
munka-támogató alkalmazást csatolnak a portálhoz. Az 
előbbire példa egy csapat-naptár, amiben a csapat tagjai látják 
egymás bejegyzéseit, az utóbbira példa a Microsoft Exchange 
Server csatolása oly módon, hogy például a felhasználó pos- 
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taládája vagy Microsoft Outlook naptára is a portálon jelenik 
meg. 

A .Net platformon futó portálmegoldás bármilyen Microsoft 
szoftverhez csatlakoztatható, sőt webszolgáltatások (webservice) 
használatával akár más platformon futó rendszereket is csatol- 
hatunk. 


Mini-alkalmazások 


Minden portálban szükségesek kicsi, egyszerű, de hasznos mi- 
niprogramok, mini-alkalmazások, amelyek a portál felhaszná- 
lói felületén található dobozkák mögötti üzleti logikát adják. A 
szavazógép, fórum, linkgyűjtemény, hírleválogató vagy hason- 
ló mini-alkalmazás megvalósítására minden gyártónak van ke- 
retrendszere. 

Fontos szempont, hogy nekünk minél kevesebb dologra kelljen 
figyelnünk, mert annál kevésbé lesz , bugos" amit írunk. A gya- 
korlat azt mutatja, hogy a teljes jogú fejlesztőnyelvek, mint a 
Visual Basic, a Cit vagy a C--4 hatékonyabban alkalmazható 
több rétegű fejlesztéshez, mint a különféle scriptnyelvek, pél- 
dául az ASP. Lényeges, hogy kódolás közben ne nekünk kell- 
jen jogosultságkezelést, cache-elést, vagy NLBS esetén sessi- 
onkezelést megvalósítanunk. A jó portál ezeket elrejti előlünk, 
ne is lássuk! 


Többrétegű fejlesztés 


Az egyszerű szoftverek egyetlen egységet alkotnak, nem mo- 
dulokból állnak össze. Az ilyen szoftvereket monolitikusnak 
mondjuk. Előnyük, hogy egyszerűek, de a folyamatos tovább- 
fejlesztésük nehézkes, főleg ha egy csapat dolgozik rajta. A 
komoly, nagy teljesítményű, skálázható és nagy rendelkezésre 
állású szoftverek gyártása más hozzáállást igényel. A komoly 
szoftverek modulokból, komponensekből állnak össze. A 
komponensek jól elkülöníthető feladatokat látnak el, egymás 
nélkül is újra felhasználhatók, külön-külön is továbbfejleszt- 
hetők vagy javíthatók, az egyes komponensek fejlesztési fel- 
adatai a fejlesztőcsapatban szétoszthatók. A portálokra pakol- 
ható dobozkák, mini-alkalmazások pedig általában több gyár- 
tótól származnak. A hálózaton keresztül működő üzleti szoft- 
verek, így a portálok nagy része is, három alapvető logikai ré- 
tegből állnak: az adatkezelésből, az üzleti logikából és a pre- 
zentációból. Az alsó réteg csak az adatokkal foglalkozik, azok 
biztonságos tárolását és előhívását valósítja meg. A második, 
középső réteg a szoftver üzleti logikáját adja, azaz azokat az 
üzleti szabályokat valósítja meg, amelyek a szoftver lényegét 
alkotják. A harmadik réteg a szoftvert prezentálja, azaz meg- 
jeleníti a felhasználónak, biztosítja a felhasználói beavatkozás 
lehetőségét, megvalósítja a felhasználói élményt. A három ré- 
teg tovább bontható, ezért az ilyen fejlesztést három rétegű 
(three tier) vagy több rétegű (n tier) fejlesztésnek szokás ne- 
vezni. 

Az olyan portálmegoldás, amely a prezentációs réteget és az 
üzleti logikát megfelelően elválasztja, azaz helyesen követi e 
többrétegű fejlesztés irányelveit, megkönnyíti a felhasználói 
felület fejlesztését. Így lesz könnyen változtatható, a cég arcu- 
latára szabható és egységes a portál felhasználói felülete. Az 
egységesség miatt nem kell az embereket többször oktatni, le- 
csökken a támogatás költsége. 


tech.net 9 RÁ wa u d 





A többrétegű fejlesztés nagy fegyelmet igényel, mert 
csak abban az esetben hajt hasznot, ha annak szabá- 
lyait pontosan betartják. A rosszul megtervezett h; 
többrétegű alkalmazás továbbfejlesztése semmivel 
sem könnyebb, mint egy monolitikus alkalmazásé. A 
jó portálmotor tehát úgy valósítja meg az alkalmazásintegrá- 
ciót, hogy keretet ad szabványos prezentációs és üzleti logika 
réteg építéséhez a fejlesztők kezébe, ezáltal elősegíti a több- 
rétegű fejlesztés szabályainak betartását. 


B 

Internet portál — 

egy tartalom, két 
"8 e prezentáció 


Fejlesztők támogatása 


Mint minden IT beruházás esetén, portál építésnél is nagy 
hangsúlyt fektetnek a szervezetek vezetői az időre. Ki ne hal- 
lott volna ,tegnapra" megrendelt Intranet, Internet vagy Extra- 
net portálokról? Mivel az idő (és általában a pénz is) kritikus 
tényező, minden lehetőséget meg kell adni a fejlesztőknek, 
hogy munkájukat hatékonyan, kényelmesen és — nem utolsó 
sorban -— jó minőségben végezhessék. A Microsoft világban az 
egyes számú eszköz a Visual Studio .NET, amely — mint min- 
den Microsoft termék — testreszabható, és kiegészíthető úgy- 
nevezett add-in modulokkal. Ha tehetjük, használjunk olyan 
portálszoftvert, amihez lehet olyan kiegészítőket kapni, ame- 
lyek segítik a szoftver konfigurálását, a dobozkák mögött rejlő 
kód fejlesztését, a tesztelést és a dokumentáció készítését! 


Szabványok 


Nem elég azonban a szabályokat betartani, és szépen megter- 
vezett több rétegű alkalmazásokat fejleszteni. Fontos, hogy 
minél több olyan szabványt alkalmazzunk, amelyeket más fej- 
lesztők is ismernek és használnak. Ha így teszünk, sokkal 
könnyebb lesz az alkalmazások integrációja, lecsökken az ok- 
tatásra szánt idő és költség, könnyebb lesz új munkaerőt be- 
vonni a fejlesztésbe. A ma kapható portálcsomagok élvonalá- 
ba tartozó termékek mind az XML-szabványra épülnek, ezál- 
tal bármilyen hardver- és szoftverkörnyezetben futó alkalma- 
zás könnyen és hatékonyan integrálható segítségükkel. 

A webszolgáltatások is szabványokra épülnek, de sajnos a pi- 
acon uralkodó üzleti harc miatt nem teljesen kompatibilisek 
egymással, noha állítólag mind a szabványokat követi. Sze- 
rencsére egyre több szoftvergyártó jön rá, hogy az inkompati- 
bilitás csak árt az üzletnek, így az SAP például a JAVA világ 
megoldásait és a .Net-et is egyformán támogatja. Az ODBC és 
egyéb szabványokról azt hiszem nem kell sokat mesélni, de 
érdemes megemlíteni a Microsoft Host Integration Servert, 
ami sok különféle nem Microsoft szoftverhez ad hozzáférést, 
illetve a Microsoft BizTalk Servert, ami pedig az elektronikus 
kereskedelmi megoldások építésénél vehet le sok terhet a vál- 
lunkról. 


Design 


Internetportáloknál gyakran felmerül az igény, hogy a portál ne 
szokványos, dobozkákból álló felhasználói felület legyen, ha- 
nem kreatív kommunikációs csatorna, amelynek csak a fantá- 
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Zia és a sávszélesség szab határt. A jó portálmotor er- 
re is lehetőséget ad, támogatja a grafikailag összetet- 
tebb, de mégis böngészőfüggetlen webdesignt. Ha a 
rendszerünk a Macromedia Flasht is megjeleníti, sőt 
dinamikus tartalommal is el tudja azt látni, teljes a 
designerek szabadsága. (Azért gondoljunk a modemesekre is, 
és kíméljük meg látogatóinkat a másfél órás intróktól.) 


Alternatív megjelenés — mobileszközök 


Ha a portálmotor a prezentációs réteget és az üzleti logikát 
megfelelően elválasztja, a portálon működő alkalmazások és a 
portálon elérhető információk alternatív böngészőkben, példá- 
ul mobileszközökön is egyszerűen megjeleníthetők. Egy tartal- 
mi elem vagy egy szolgáltatás megjelenését több böngészőre 
vagy eszközre lehet optimalizálni. Amíg egy bizonyos megje- 
lenítő gazdagon díszített DHTML vagy XHTML kimenetet állít 
elő asztali számítógépen futó, újabb verziójú böngészők szá- 
mára, egy másik megjelenítő előállíthat egyszerű HTML, WAP 
vagy XML kimenetet is, amit mobileszközök, kézi számítógé- 
pek, mobiltelefonok vagy régebbi böngészők is kiválóan meg 
tudnak jeleníteni, akár igen lassú Internet kapcsolaton keresz- 
tül is. 


Közgáz - ROI 

A portálprojektbe fektetett idő és pénz sokféleképpen térülhet 
meg. A dolgozók hatékonysága megnő, információk után való 
szaladgálás helyett valami értelmeset és hasznosat tesznek. Jó 
környezetben jobb dolgozni, és jó kedvvel minden munkatár- 
sunk hatékonyabb. Főnökeink, ügyfeleink vagy beszállítóink 
jólinformáltak lesznek, könnyebben és gyorsabban hoznak 
olyan döntéseket, amelyek nekünk hasznot hajtanak. A fenti 
előnyöket nehezebb számokban kifejezni, de egyes kutatások 
rámutatnak, hogy az egységes, központosított infrastruktúrán 
megvalósított Intranet-, Extranet- és Internetportálok megtérü- 
lése igen gyors. Ha pedig több kicsi portálra van szükségünk, 
akár szervezeti egységek, akár témák szerint, mindenképpen 
válasszunk olyan portált, ahol az információk több portálon is 
megjeleníthetők. Figyeljük meg, hogy a közös infrastruktúra 
megléte kihat a TCO-ra is. 


Közgáz - TCO 

A megfelelő felügyeleti eszközök, logolvasók, adatbáziskar- 
bantartó scriptek, öndokumentáló karbantartási eljárások, táv- 
felügyelet, automatikus felügyelet és öndiagnosztika mind 
csökkentik a portál birtoklásának összköltségét. Ha például az 
adminisztrációs felület szintén egy portál, azaz webes alkalma- 


zás, nem kell klienseket telepíteni. Ez az intranet egyik legna- 
gyobb, bár nem egyetlen előnye. Az NLBS lehetőséget ad a gé- 
pek egyenkénti, teljes leállás nélküli frissítésére, így nincs mun- 
kaidőkiesés. Ez az úgynevezett rolling upgrade lehetősége a 24 
órában az Internetre kötött rendszerek esetében még a legfor- 
róbb tűzfal mellett is kritikus a biztonság szempontjából. 


Zárszó 


Természetesen ebbe a cikkbe sem fér bele minden, amit a por- 
tálokról tudni érdemes. Az alkalmazásszerverek, a tranzakció- 
kezelés, a biztonság, a többnyelvűség vagy az off-line elér- 
hetőség kérdései szintén igen fontosak. Kérek mindenkit, hogy 
véleményét juttassa el e-mailben az írónak, vagy a szer- 
kesztőségnek, ezzel is segítve a sorozat következő témájának 
kiválasztását. Végezetül álljon itt egy checklist arról, mit tud a 
jó portál: 


XML-, XSLT-alapú prezentáció 

Web Service, SOAP támogatás 

Intranet, Internet, Extranet egy rendszerben 
Skálázhatóság és nagy rendelkezésre állás 
Fejlesztő, tesztelő és dokumentáló eszközök 
Tranzakciókezelés lehetősége 

Beépített cache, és cache API 

Egy jelszó, SSO 

Kereső, Indexelő megoldás, kereső API 
CMS, sablonok 

Biztonság, titkosítás, SSL (https:// 
Mobileszközök támogatása 
Többnyelvűség, Magyar GUI 

Hazai support. 


BEBBBBHBB BB BBB 


Ha mindezeket figyelembe vesszük, és az üzleti célokra is oda- 
figyelünk, az eredmény egy dinamikus portál, amely nagy ren- 
delkezésre állás mellett képes kiszolgálni az üzleti igényeket és 
az egyre növekvő terhelést, jöjjön az házon belülről vagy há- 
zon kívülről. 

A felhasználói élményt az Egy Jelszó és a mini-alkalmazások 
adják, a rendszerintegrátorok és fejlesztők munkáját pedig a 
szabványokra épülő többrétegű fejlesztőkörnyezet és a fejlesz- 
tést segítő eszközök biztosítják. Sok sikert! 


Bíró Tamás 
btGsensenet.hu 
MCSD 
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Sokszor esett már szó az Active Directory eléréséről, bűvöléséről, most azonban a saját kódból törté- 
nő elérést szeretném bemutatni, illetve illusztrálni néhány példán keresztül. Ugy gondolom, ezek az 


ismeretek mind fontosak lehetnek egy AD-integrált alkalmazás fejlesztésekor. 


Első lépésként néhány technológiát szeretnék bemutatni, ame- 
lyek segítségével hozzáférhetünk az Active Directory tartalmá- 
hoz. 


LDAP (Lightweight Directory Access Protocol) 


Az LDAP alacsony szintű kódok segítségével teremt közvetlen 
kapcsolatot a kliens és az Active Directory között. Legbelül a 
többi, közkedvelt kapcsolódási technológia, az ADSI és a 
COM is ezt használja. Természetesen ez utóbbiak lassabbak, 
mivel magasabb szintű szolgáltatást nyújtanak. 


Windows 2000 Server 


B 
Az LDAP struktúrája 





Az LDAP segítségével mindemellett nemcsak az AD kezelhe- 
tő, hanem bármely címtárszolgáltatás is. 


ADSI (Active Directory Service Interface) 


Az ADSI egy COM-alapú, LDAP-on keresztül kommunikáló in- 
terfész, amely minden olyan esetben használható, ahol a COM- 
os megoldások megállják helyüket. Kevesebb kódot igényel, 
mint az LDAP, viszont működése lassabb is. Mind kliens-, mind 
szerveroldalon telepíteni kell (a Windows2000-rel automati- 
kusan jár). 








Client 


) 


DSI OLE DB provide 
ADS e 


SI LDAP providei1 


Windows 2000 Server 
a 
Az ADSI struktúrája 


A kliens vagy közvetlenül az ADSI-val kommunikál, vagy 
ADO-n keresztül éri el azt. Az ADSI alatt még egy réteg, az 
LDAP provider helyezkedik el, a kommunikáció közvetlenül 
ezen keresztül zajlik. 


CDO (Collaboration Data Objects) 


A CDO szintén COM-alapú technológia, viszont kevésbé gaz- 
dag, mint az ADSI. Kliensoldalra nem lehet installálni, így több 
feladat hárul a kiszolgálóra. 


Jogosan merül fel a kérdés, hogy a fenti megoldások közül mi- 
kor melyiket érdemes alkalmazni. Hasonlóságuk alapján az 
ADSI-t és a CDO-t érdemes összehasonlítani, hiszen alacsony- 
szintű, nagysebességű megoldásával a , csupasz" LDAP külön 
kategóriát képez. 

Egy igen jelentős szempont, hogy kliens- vagy szerveroldali al- 
kalmazást írunk-e. Ha a kiszolgáló feladatait minimálisra sze- 
retnénk csökkenteni, az ADSI-t célszerű használni, míg ellen- 
kező esetben CDO-t. CDO ajánlott akkor is, ha az alkalmazá- 
sunk gyakran hoz létre vagy módosít felhasználókat, Exchange 
mailboxokat és mozgat információkat az AD és a WSS mappák 
között. Ha általános AD-kezelési feladatok elvégzését szeret- 
nénk egyszerűen megvalósítani, az ADSI használata javasolt. 
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Az LDAP elérési út 


Bármelyik megoldást választjuk is, mélyen legalul 

LDAP-ot használunk, így nélkülözhetetlen az LDAP 

formátumú elérési utak ismerete: az ADSI az objek- 

tumokhoz történő hozzáféréshez (binding), a CDO 

az adatforrás megnyitásához használja őket. 

Az LDAP név alakja a következő: LDAP : / /server/DN. A 

server egyértelműen a kiszolgáló neve, a DN pedig az Acti- 

ve Directory-beli objektum neve (distinguished name). Ha DN- 

t nem adunk meg, a beléptetés megtörténik az aktuális felhasz- 

náló nevében, és az ő jogaival látjuk az Active Directory leg- 

felső szintjét. 

A DN három részből áll: 

1. CN (common name): az objektum neve. 

2. ou (organizational unit): — az a szervezeti egység, ahova az 
objektum tartozik 

3. pc (domain controller): a domain controller nevének da- 
rabjai (például DC-msdn, DC-microsoft , DC-com) 


A DN a fenti elemek tetszőleges kombinációját tartalmazhatja, 
azonban a sorrend kötött (a fenti felsorolás szerint). Így példá- 
ul egy LDAP név lehet a következő: 





A Property cache 


Mivel az alkalmazásunk igen kevés esetben futhat magán a 
szerveren (a domain controlleren), a hálózat terheltségének 
csökkentése érdekében a kliens és szerver közötti kommuni- 
kációt minimalizálni kell (és az alkalmazásunk is gyorsabb 
lesz így). 

A kliens gépen egy úgynevezett property cache jön létre, 
amelybe a szerverről érkezett adatokat elhelyezzük. Ha az AD- 
ból valamilyen új adatot kapunk, elhelyezésre kerül ebben a 


. Windows2000 szerver 


. Property Cache. 
. Get, GetEx 
Put, PutEx 





cache-ben, és legközelebb közvetlenül innen érhetjük el. 

Az AD adatait az ábrán látható metódusokkal kezelhetjük. El- 
ső alkalommal feltöltésre kerül a property cache. Ez egyrészt a 
Get vagy GetEx metódus meghívásával, implicit történhet, me- 
lyek — mivel az adat nem található a cache-ben — az AD-hez 
fordulnak; másrészt explicit módon, a Getlnfo meghívásával. 
Ha a cache-t feltöltjük, a Get és GetEx metódusok előbb onnan 
próbálják kinyerni a kívánt adatot, s csak sikertelenség esetén 
fordulnak a szerverhez. A Getlnfo mindig a szerverhez nyúl az 
adatokért. 

A jellemzők cache-beli értékeinek beállításához a Put és PutEx 
metódusok használhatók. Ezek mindig a cache-be írnak, akkor 
is, ha az adott jellemző korábban még nem szerepelt ott. Ké- 
sőbbi Get eredményeképp az AD-ből bekerülő adatok felülír- 
ják a Put által oda helyezetteket. Ezért legalább egy Get metó- 
dusnak meg kell előznie a Put-okat. 

Az AD-be történő íráshoz a Setlnfo metódus használható. Ez a 
cache-ben található összes adatot feltölti az Active Directory- 
ba. Ha valamely érték érvénytelen, akkor hibaüzenetet ka- 
punk. 
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A Get és GetEx, illetve a Put és PutEx metódusok között az az 
alapvető különbség, hogy az előbbiek egyetlen érték kezelésé- 
re használandók, míg az utóbbiak többértékű jellemzők olva- 
sására illetve írására szolgálnak. 


Az Active Directory felhasználókat reprezentáló elemei 


Az AD-ben kétféle objektum reprezentálhat személyeket: a 
Contact és a User. Mindkét típus képes e-mailek fogadására, de 
csak a User-hez rendelhető Exchange mailbox és security kör- 
nyezet. 

A személyeket megtestesítő objektumok a Person sémaosztá- 
lyon alapulnak. Egy Contact-objektum egy olyan AD-bejegy- 
zés, amely alapvető információkat tartalmaz egy személyről: 
név, cím, telefonszám, stb. A User-objektum , security princi- 
pal": be tud lépni a hálózatra, és különböző jogosultságokkal 
rendelkezik a hálózati erőforrásokhoz (nyomtatás, fax, stb.). A 
Contact-nak nincsenek ilyen jogosultságai, csupán adataival 
szerepel az Active Directory nyilvántartásában (ennek célja 
például az, hogy könnyedén hozzáférhessünk, levelet küldhes- 
sünk neki stb., viszont az illető személy ne garázdálkodhasson 
a vállalati hálózaton). 


seeAlso 

sn 
telephoneNumber 
userPassword 





5 Contact és User elemek az Active Directoryban 


A fenti ábra tehát a Person osztályból történő leszármazást mu- 
tatja. (Annyi apró , trükk" került az ábrába, hogy az objektum- 
osztályokat szemléltető téglalapok középső részén a kötelező, 
míg alsó harmadában az opcionális attribútumokat tüntet- 
tem fel.) 


Az Active Directory séma 


A séma az Active Directory objektumait írja le. Mivel a séma- 
definíció maga is az Active Directoryban, objektumok formá- 
jában tárolódik, ugyanúgy adminisztrálható, mint bármely 
hétköznapi" Active Directory objektum — természetesen a 
megfelelő jogosultságok birtokában. 

A séma kétféle objektumot tartalmaz: osztály- és attribútum-le- 
írásokat. Ezeket összefoglaló néven általában sémaobjektu- 
moknak vagy metaadatoknak nevezzük. 

Az osztályleíró objektumok az Active Directory objektumainak 
lehetséges típusait határozzák meg. Sablonként funkcionálnak, 
melyeket új objektum létrehozásakor használhatunk, és annak 





leírására szolgálnak. Azokat az attribútumokat tárolják, ame- 
lyek az adott típusú objektumok jellemzőiként funkcio- 
nál(hatnak. 

Minden AD-beli objektum valamely AD-osztály példánya. 

Az attribútumleíró sémaobjektumok az Active Directory-beli 














ellemzőket, attribútumokat írják le. Minden attribútumot egy- 
szer kell definiálni, később annyi osztályban használhatjuk, 
ahányban csak jólesik. 
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E Az Active Directory séma - osztályok és attribútumok 
leírása 


A Windows2000 Serverrel szállított alap-séma természetesen 
kibővíthető. Fontos tudni, hogy a sémába újonnan felvett ele- 
mek soha többé nem törölhetők onnan, típusuk, nevük nem 
változtatható, így rendkívüli körültekintést igényel a séma bő- 
vítése (mi azonban természetesen megpróbálkozunk vele a ké- 
sőbbiekben O). 


Az alábbi táblázat az osztályleíró sémaobjektum kulcsfontos- 
ságú attribútumainak listáját tartalmazza: 





LDAPDisplayName 





cn (Common Name) Minden AD objektum rendelkezik egy 
őt azonosító névvel, amely az ő RDN- 
je. A classSchema megnevezésére a 
en szolgál. A cn-nek egyedinek kell len- 
nie a schema mappán belül. 


Az LDAP kliensek által használt név, 
ennek segítségével hivatkozhatunk az 
osztályra. A séma mappán belül egyedi- 
nek kell lennie. 


schemalDGUID 


LDAPDisplay Name 


Nyolc karakterből álló (octet) string. 
Egyedi, az osztály azonosítására szol- 
gál. A bejegyzésekhez történő hozzáfé- 
résre használható. 

Ha új classSchema-t hozunk létre, az 
AD automatikusan legenerálja, ameny- 
nyiben mi nem készítünk saját GUID- 
ot. Ajánlott saját azonosítót létrehozni 
minden osztályhoz. 


Az adminisztrációs eszközökben meg- 
jelenő név. Ha nem specifikáljuk, ami- 


adminDisplay Name 
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t 


kor létrehozunk egy osztályt, a rendszer 
a CN-t használja. (Csak akkor használja 
a rendszer, ha a classDisplayName 
bejegyzés üres.) 





Ezek a többértékű jellemzők azt specifi- 
kálják, hogy mely attribútumokat köte- 
lező beállítani az adott osztály példá- 
nyain. Kötelező attribútumok, amelye- 
ket már az objektum létrehozásakor be 
kell állítani, és a későbbiek során sem 
törölhetőek, sőt nem is változtathatók. 


mustContain, 
systemMustContain 





Ezek a többértékű jellemzők azt specifi- 
kálják, hogy mely attribútumokat állít- 
hatjuk be az adott osztály példányain. 
Ezek opcionális attribútumok, megadá- 
suk nem kötelező. 1. és 2. kategóriás 
classSchema objektumból egyaránt 
válogathatunk ide. Mielőtt az osztályde- 
finícióból törlünk egy attribútumot, az 
összes példányból ki kell az törölni. Az 
osztály létrehozása után a system- 
MayContain jellemző nem módosít- 
ható. 

Az opcionális attribútumok teljes hal- 
maza a systemMayContain és a 
mayContain uniója, ezen és az összes 
örökölt osztályon. 


mayContain, 
systemMayContain 


Azokat a strukturális osztályokat specifi- 
kálja, amelyek valódi szülei lehetnek 
ezen osztály példányainak. A teljes 
készlet e két jellemző, és az örökölt 
strukturális vagy absztrakt osztályok 
uniója. A jellemzők értékei az örökölt és 
kisegítő osztályokra nem érvényesek. 

A possSuperiors bármikor változtatható, 
törölhető, a systemPossSuperiors vi- 
szont az osztály létrehozásakor állítható 
be, később nem módosítható, és nem 
távolítható el. 


possSuperiors, 
systemPossSuperiors 





Integer érték, mely az osztály kategóriá- 
ját mutatja. 


objectClassCategory 





subClassOf Az osztály közvetlen ősosztályának 
OID-je. 

A hivatkozott ősosztálynak léteznie kell, 
különben meghiúsul az osztály hozzá- 


adása a sémához. 





Öröklődés 
Természetesen az Active Directoryban is definiált az öröklődés 
fogalma. Minden objektumosztály a speciális, legfelső top osz- 
tály leszármazottja. A top kivételével minden objektumosztály 
leszármazottja valamely másik osztálynak. (Tehát az egész hi- 
erarchia egy fába rendezhető, amelynek gyökéreleme a top 
osztály.) Néhány attribútum értéke az ősosztályból öröklődik, 
ilyenek például: 
A Lehetséges attribútumok. Egy classSchema objek- 
tum mustContain, mayContain, systemMust- 
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Contain és systemMayContain attribútumérté- 
kei határozzák meg azon attribútumok teljes listáját, 
amelyek egy osztály példányán megjelenhetnek. 
Minden egyes objektumosztály örökli a fenti attribú- 
tumok értékeit az ősosztályától, és minden értéket er- 
re állít be. 
A Lehetséges ősök a directory hierarchiában. A poss- 
Superiors és systemPossSuperiors attribútu- 
mok definiálják azon objektumosztályok teljes listáját, 
amelyek tartalmazhatnak objektumosztály-példányo- 
kat. Minden objektumosztály az ősosztályától örökli 
ezeket az értékeket. 





.a. részt Developer 






Organizational Person 
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Az Active Directory programozott elérése 


de 
se] 
B Öröklődés az Active Directoryban 
Ennyi bevezetés után térjünk végre a lényegre, hiszen progra- 
mozásról eddig szó nem volt. A nyitott kérdéseket folyamato- 


san, a programozási problémák ismertetése és megoldása köz- 
ben zárom majd le. 
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Néhány egyszerű programozási feladat 


Objektum létrehozásához első lépésként aktív kapcsolatot kell 
kiépítenünk azzal a mappával, ahova létre akarjuk hozni az új 
objektumot (felhasználót, csoportot, stb.), majd meghívjuk az 
IADsContainer interfész Create metódusát. Ez szolgál ob- 
jektumok létrehozására, és két paramétere van: 

TA A létrehozandó objektum sémaosztályának neve (pl. 

group, user, stb.) 
TA Az új objektum relatív DN-je (pl. CN-Agnes) 


Új csoport létrehozására szolgál az alábbi kódrészlet: 





Hasonló módon hozhatunk létre például felhasználókat is, ez 
esetben az IADsGroup helyett az IADsUser, általános 
Active Directory-objektum esetében az IADSs interfész hasz- 
nálandó. 


Objektumok törlése is hasonló, egyszerű módon végezhető, a 
. Delete metódus segítségével. Például felhasználót így töröl- 
hetünk: 





Ezekből az egyszerű kódokból jól látható, hogy az Active Di- 
rectory ,bütykölése" nem nagy ördöngösség. De vajon bonyo- 
lultabb, összetettebb feladatokra igaz-e ez? Például a sémamó- 
dosítás is ilyen egyszerűen végrehajtható? Ehhez hasonló kér- 
désekre keressük a választ a következő hónapokban. Segítsé- 
gül ismét egy összetettebb példát hívok, hogy ezáltal szemléle- 
tesebben és érthetőbben vezethessek be mindenkit az AD 
programozásának rejtelmeibe. j 
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A Petri-hálók további alkalmazásai 


A sorozat első részeként áttekintettünk néhány alapfogalmat az informatikában használatos formális 
módszerekkel kapcsolatban, majd áttértünk a Petri-hálókra. A topológia bemutatása után most mé- 


lyebb részleteket szeretnék bemutatni. 


A kapacitáskorlát kiküszöbölése 


Lássunk egy nagyon egyszerű példát. Az alábbi ábrán egy ka- 
pacitáskorlátos Petri-háló látható, melynek működése könnyen 
leírható: a kiindulási helyzetben egyetlen tokenünk van, a P1 
helyen. A T1 tranzakció tüzelési feltétele, hogy P1-en legyen 
token, ezúttal ez teljesül. A T2 tranzakció jelenleg nem enge- 
délyezett, hiszen P2-ben nincs token. 
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E3 Egyszerű kapacitáskorlátos Petri-háló 


ATI tranzakció tüzeléskor T2-be 2 tokent tesz, vagyis eggyel 
növeli a rendszerben keringő tokenek számát. T2 ezt a szum- 
ma tokenszámot nem változtatja, csupán elvesz P2-ből egyet, 
és azt P1-be helyezi át. 

Jól látható, hogy TI minden egyes tüzelése eggyel megnöveli a 
tokenek számát, vagyis nincs felső korlát arra, hogy a rendszer- 
ben mennyi token lesz, ha tetszőlegesen hosszú ideig magára 
hagyjuk futás közben. Ezáltal arra sem tudunk korlátot adni, 
hogy egy-egy állapotban hány tokenünk lesz. Ezt hivatott meg- 
oldani a kapacitáskorlát, amiről előző cikkemben már írtam. 
Ha bevezetünk egy K(P2J-4 kapacitáskorlátot, az azt jelenti, 
hogy a P2 helyen maximum 4 token lehet egyszerre, s ez a T1 
tranzíció tüzeléséhez is egy újabb, korlátozó feltételt jelent (ha 
P2-n már 4 token tartózkodik, akkor a TI tüzelése nem enge- 
délyezett, hiába van token P1-en). 

Ez a módszer megoldást jelent tehát bizonyos problémákra, 
sajnos azonban több analízis-módszer (ezekről lásd később) 
nem támogatja használatát, így amit nyertünk vele az egyik ol- 
dalon, azt megfizetjük a másikon. De mi furfangos és telhetet- 
len informatikusok lévén szeretjük megkeresni a kiskapukat. 
Így teszünk most is, vagyis funkcionalitásukban kapacitáskorlá- 





tos helyeket szeretnénk megvalósítani konkrét kapacitáskorlát 
nélkül. 

Vajon hogyan lehetséges mindez? 

Gondoljunk bele, mi történik a P2 hellyel, amikor elveszünk 
onnan, illetve teszünk oda tokent. Tegyük fel, hogy P2 egy ka- 
pacitáskorlát nélküli (végtelen korlátos) hely, és kezdetben 
nincs ott token (ez a helyzet a fenti példában is). Képzeljük el, 
hogy a P2 helyen (a híd lábánál) egy törpe ücsörög, akinek üres 
az erszénye. Ha arra jár egy lovag (és mondjuk keleti irányba 
tart), egy garas vámot szed tőle, ha viszont ugyanez a lovag 
visszafelé jön, visszakapja a garasát. Így a törpénél átmenetileg 
lehetnek a garasok, és maximum annyi, ahány lovag kelet felé 
elhaladt. 





B A törpe és a lovag 


Ha a törpe zsebébe k darab garas fér el, egyszerre k lovag le- 
het a hídtól keletre (tegyük fel, hogy a világ azon felén erede- 
tileg nem éltek lovagok). Ebben az esetben csak akkor mehet 
át a hídon a következő lovag, amikor egy másik visszatér. (For- 
málisan: a Lovag átlép tranzíció csak akkor engedélyezett, ha 
a Kelet állapotban k-nál kevesebb token van.) 

Igen ám, de ha mesebeli törpénk zsebe feneketlen, elvileg 
akárhány lovag lehet a keleti, és a nyugati oldalon egyaránt. 
Hogyan oldható meg ekkor, hogy a sok lovag ne árassza el a 
keleti oldalt? Ennek egyetlen módja van: kevés embert kell 1o- 
vaggá ütni. Ha az Óperenciás tengeren túli király gondoskodik 
arról, hogy országában összesen k lovag legyen (és semmikép- 
pen sem több), akkor egészen biztos, hogy a keleti oldalon so- 
hasem lesz k-nál több lovag. Ebben az esetben, ha keleten x 
számú lovag van, akkor nyugaton egészen pontosan k-x. 

Mit jelent ez a Petri-hálók nyelvezetére lefordítva? 

Ha azt akarjuk elérni, hogy a P2 (kelet) helyen maximum k-4 
darab token legyen, be kell vezetnünk egy adminisztrációs he- 
lyet (P29, ahol azt tartjuk számon, hogy a P2 helyre hány to- 
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ken fér még el (nyugat). Így az adott helyen lévő to- 
kenek számát m-mel jelölve mindig igaz lesz az 
alábbi összefüggés: m(P29--m(P2J-k. 

De hogyan felügyelhető, hogy ez minden esetben így 
legyen? Kezdetben a P2" helyen legyen k darab to- 
ken, P2-n pedig 0. A P2-vel szomszédos tranzakciókhoz ve- 
gyünk fel új éleket az alábbiaknak megfelelően: ha a tranzíció 
a darab tokent vesz el a P2 helyről, akkor az új élen adjon a 
darabot a P2"-höz. Ha pedig b tokent ad P2-höz, akkor ugyan- 
ennyit vegyen el P2"-ből. A fenti példából kiinduló Petri-hálónk 
tehát így néz ki: 





B A módosított Petri-háló kapacitáskorlát nélkül 


A módosított T1 tranzíció tehát nemcsak hozzáad P2-höz 2 db. 
tokent, hanem ugyanennyit el is vesz a P2" adminisztrációs 
helyről. Hasonlóan T2 elvesz 1 tokent P2-ből, és hozzáad 
egyet P2"-höz. 


Szimuláció Petri-hálókkal 


A Petri-háló tevékenységeit, akcióit olyan elemi (atomi) esemé- 
nyekre bontjuk, amelyek tovább már nem oszthatóak. Esetünk- 
ben atomi eseménynek mondunk egy tranzíció tüzelését, így 
az összetett események a tüzelési szekvenciákat jelentik (az 
egymás után végrehajtható tüzelések sorozatát). Az eseménye- 
ket a rendszerben szereplő állapotváltozókkal szimuláljuk. 
Petri-hálók számítógépes szimulációjához több dolgot figye- 
lembe kell venni. A nemdeterminisztikus viselkedés miatt az 
időzítéseket (állvéletlen módon kell megoldani, tehát ha több 
tüzelhető tranzíció is van egy adott időpillanatban, véletlen- 
szerűen válasszuk ki azt, amelyik a következő alkalommal va- 
lóban tüzelni is fog. Ilyenkor azonban fennáll annak a veszé- 
lye, hogy ha egy tranzíció tüzel, olyan tranzíciók is tiltottá vál- 
hatnak, amelyek az előző lépésben még engedélyezettek, illet- 
ve olyanok válhatnak engedélyezetté, amelyek korábban tiltot- 
tak voltak. Lássuk például az alábbi ábrát: 
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E Példa Petri-háló szimulációjára 


A fenti ábrán látható kezdőállapotban mind a T1, mind a T2 
tranzíciók engedélyezettek. Ha a véletlenszerű döntés után a 
T1 tüzel elsőként, több változás is beáll a rendszerben: a token 
a P1 helyről átkerül a P2-be, ezáltal a T1 és T2 tranzíciók letil- 
tódnak. Ugyanakkor a T3 engedélyezett lesz, hiszen bemene- 
tén egyetlen hely, a P2 szerepel, és ott is csupán a tokennek 
kell állnia, ez a feltétel pedig ekkor teljesül. 

Ha meg akarjuk tehát valósítani a Petri-hálók algoritmusát, fi- 
gyelembe kell venni ezeket a letiltódásokat és engedélyeződé- 
seket. Első megközelítésben tehát végigvizsgáljuk az összes 
tranzíciót, hogy teljesül-e rá a tüzelési feltétel: ha igen, hozzá- 
adjuk az engedélyezettek listájához (ha eddig még nem szere- 
pel rajta), illetve ha nem, elvesszük a listából. 

Ezáltal elérjük, hogy minden tüzelés után aktuális képünk van 
a tüzelhető tranzíciókról, azonban ez a megvalósítás meglehe- 
tősen lassú: minden tüzelés után minden tranzíciót végig kell 
vizsgálnunk. Természetesen ennél hatékonyabb megvalósítás 
is lehetséges, ha figyelembe veszünk néhány egyszerűsítő 
tényt. Jelölje a T tranzíció őseit (bemeneti helyeit) "T, utódait 
(kimeneti helyeit) pedig Te. Hasonlóan jelöljük a eP hely őse- 
it és utódait P-vel és Ps -tal. Vegyük észre, hogy egy T tranzí- 
ció tüzelésekor csupán a "eT helyekről veszünk el tokent, így 
csak azt kell vizsgálni, hogy ezen helyek utódai (azaz a (9T)"e 
traníciók) tüzelhetők-e a továbbiakban (vagy letiltódtak). Ha- 
sonlóan a T tranzíció tüzelésekor csak a T utódaiba kerül to- 
ken, így ezek módosíthatják a további tüzelhetőséget, azaz 
(T9)s vizsgálatával állapíthatjuk meg, hogy engedélyeződtek-e 
újabb tranzíciók. 

A fenti példában tehát T1 tüzelésekor a (9T1)-(P1) állapotból 
veszünk el tokent, azaz a ((eT1)e)-((P1]9)-(TT,T2] tranzíció- 
kat kell csupán megvizsgálni (T3 nem tiltódhatott le akkor sem, 
ha engedélyezett volt, mert nem utódja T1 egyetlen ősének 
sem). Ekkor azt kapjuk, hogy mind T1, mind T2 tiltott állapot- 
ba került, ugyanis bemenetükön nincs meg a megfelelő számú 
token. 

Lássuk, lett-e engedélyezett token. T1 utóda egyedül a 
(T19)-(P2) hely. P2 utód-tranzíciói: ((TT 9)9)-((P2]9)-(T3]. T3 
vizsgálatakor kiderül, hogy eddig ugyan tiltott volt, most azon- 
ban már van a bemenetén a szükséges számú (7 db) token, te- 
hát engedélyezett lett. Ha lenne a hálóban több tranzíció, azok 
tüzelhetősége nem változna, hiszen T1 tüzelése csupán a köz- 
vetlen környezetét változtatja meg. 

A tüzelhetőség vizsgálata elsősorban olyan esetekben jó, ami- 
kor arra vagyunk kíváncsiak, hogy a hálóban van-e holtpont 
(deadlock). Ennek vizsgálata létfontosságú, ugyanis a nem holt- 
pontmentes rendszerek működésének folytonossága nem biz- 
tosított, fennáll annak lehetősége, hogy olyan helyzetbe kerül- 
ne, ahonnan sehova sem tudnak továbblépni (nincs egyetlen 
engedélyezett tranzíció sem). Ekkor a szimulált rendszer ,be- 
fagy", többé nem működőképes. Ez pedig végzetes lehet. 


Tervezési példa Petri-hálókkal 


Az elmúlt hónapban példaként szerepelt egy kétemeletes lift, 
amelynek akkor állapotautomatáját rajzoltuk fel. Most ennek 
Petri-hálós megvalósítását szeretném bemutatni. 

Először is azonosítsuk a feladatunkban szereplő állapotokat 
(ezek lesznek a Petri-háló helyei) és állapotátmeneteit (ezek 
lesznek majd a tranzíciók). 

A lift minden egyes szinten lehet nyugalmi állapotban (/dle), ha 
éppen sehova sem hívták, és utasa sincs. Ha éppen megérke- 
zik egy emeletre, Erkezes állapotba lép, melyet az ajtó zárása 
előz meg, illetve az ajtó nyitása követ, természetesen a megfe- 
lelő emeleten. 

cn.ne 
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Az egyes állapotok közötti átmeneteket különböző események 
váltják ki. Nyugalomba akkor kerül a lift az adott szinten, ha 
teljesítette feladatát, és nincs több utasítás számára. Az ajtó ak- 
kor záródik be, ha elhívják a liftet: ekkor vagy nyugalomból 
ébred fel", vagy korábbi mozgását folytatja a megfelelő irány- 
ba. Ajtaját akkor nyitja, ha megérkezett egy emeletre. 

Az ajtó záródását és egy másik emeletre történő érkezést a lift 
adott irányú mozgása választja el egymástól. Ajtózáródás- és 
nyitódás nélkül csak akkor mozoghat a lift, ha áthalad egy 
emeleten. Esetünkben ezt egyedül az első szinten teheti meg. 
Az alábbi ábra egyetlen szint Petri-hálóját mutatja, ahol a töb- 
bi szinten történő mozgást és egyéb tevékenységeket a Mozog 
tranzíció hivatott helyettesíteni, abból a megfontolásból, hogy 
ha állunk egy emeleten és várjuk a liftet, lényegtelen, hogy az 
merre kószál az épületben, csak az számít, hogy éppen aktuá- 
lisan számunkra nem érhető el. (Természetesen itt attól a lé- 
nyeges tényezőtől eltekintünk, hogy esetleg sietünk valahova, 
így kardinális jelentőségű lehet az az információ is, hogy a lift 
éppen melyik állomáson tartózkodik.) További feltételezésünk 
az egyszerűség érdekében, hogy a lift soha nem hibásodhat 
meg. Ha mégis szeretnénk ezt a lehetőséget is megfelelően le- 
kezelni, minden állapotból a megfelelő tranzíción keresztül 
egy hibakezelő állapotba kell elvezetni a liftet, majd onnan 
vissza. 
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A lift egyetlen emelet szemszögéből megfigyelve 


A mozgást a nyugalmi állapotból kiindulva figyeljük meg (ezt 
szimbolizálja az ott elhelyezett token). Az, hogy az egész há- 
lóban egyetlen token kering, azt mutatja, hogy a lift egy időben 
mindig egy és csakis egy állapotban lehet. 

Ha valahová elhívják a liftet (vagy beszáll egy utas, és ő utasít- 
ja mozgásra), az ajtó bezáródik (Ajtot zar), és a lift telje- 
síti a feladatot (Mozog) . Hogy pontosan hova megy, és útköz- 
ben milyen egyéb feladatokat kap, az számunkra lényegtelen. 
Ha feladatát teljesítette, feltételezésünk szerint előbb-utóbb 
visszaérkezik erre a szintre (Szintre er), majd kinyitja az 
ajtót (Ajtot nyit) . Ha a végrehajtandó utasítások tára üres, 





ű [ 
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ezen a szinten marad (Marad) , és visszatér nyugal- 
mi állapotba. Ha azonban még van mit tennie (To- 
vabbhivas) , újra bezárul az ajtó, és az előzőekhez l 
hasonlóan folytatódik a lift tevékenysége. 


Lássuk most, mi történik, ha a liftet teljes valójában szeretnénk 
szemlélni, azaz nem csupán egyetlen emelet szemszögéből, 
hanem teljes viselkedésére kíváncsiak vagyunk. Vegyünk egy 
kétemeletes épületet. Mivel ennek három szintje van (földszint, 
1. emelet, 2. emelet), három, az előzőhöz hasonló alhálóból 
épül majd fel a modellünk. A három részháló egymás mellé 
helyezése után egyedül azt kell megoldanunk, hogy ezek a 
megkövetelt funkcionalitásnak megfelelően össze is legyenek 
kapcsolva. 

Először is azt kell megoldanunk, hogy ha egy adott szinten be- 
záródik az ajtó, a következő állapotban valamely szomszédos 
emeletre érkezzen meg a lift. Erre szolgálnak a következő tran- 
zíciók: Felmegy 0-1,  Lemegy 1-O;  Felmegy 1-2, 
Lemegy 2-1. Acwtranzíció neve természetes módon utal a 
mozgás irányára, a benne szereplő számok pedig értelemsze- 
rűen azt jelzik, mely két emelet között történik a mozgás. 

Azt az esetet azonban még így sem kezeltük le, amikor vala- 
mely szinten egyszerűen csak áthalad a lift megállás nélkül. 
(Képzeljük el, milyen kényelmetlen lenne, ha a valóságbeli lif- 
tek úgy működnének, hogy minden egyes emeleten megállná- 
nak, kinyitnák ajtajukat, majd függetlenül attól, hogy van-e ki- 
és/vagy beszálló utas, mindig várnának egy bizonyos időt, s 
csak utána zárnák ajtajukat és indulnának tovább.) Erre az eset- 
re újabb két tranzíciót kell bevezetnünk, a Halad le 1-0, és 
a Halad fel 1-2-t. Ellentétes párjukra azért nincs szükség, 
mert például a földszint és az emelet között egészen biztosan 
csak földszinti ajtózáródás után tud haladni, hiszen a földszint 
alatt nincs több szintünk. 

A következő oldalon látható árba ezt a kibővített, háromszin- 
tes épületre vonatkozó lift Petri-hálós modelljét mutatja be. 
Joggal merül fel a kérdés, hogy hogyan bővíthető tovább ez a 
modell három-, négy- esetleg több emeletes épület liftjének ke- 
zelésére. Bővíthető-e egyáltalán? 

A válasz természetesen igen. Mégpedig oly módon, ahogyan 
az egyetlen szintből kiindulva konstruáltuk a háromszintes mo- 
dellt: a második emeletről felfelé történő mozgást például első 
lépésként modellezzük egyetlen Mozog 2 nevű tranzícióval, 
amelynek bemenő helye az Ajtot zar 2, kimenő helye pe- 
dig a2 emeletre er hely. Következő lépésként ezt a tran- 
zíciót helyettesítjük a megfelelő rész-hálókkal, az igényelt 
szintek számának megfelelően. 
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A liftautomata Petri-hálója 


em 


De vajon ,jó"-e a fent megalkotott Petri-háló? És egyáltalán: 
mit értünk a háló jóságán? 

Egyik fontos kritérium lehet, hogy a háló holtpont-mentes le- 
gyen, azaz ne tartalmazzon olyan tranzíciót, amely bizonyos 
feltételek mellett ,befagyhat", azaz nem tud üzemelni. Ha 
megnézzük a liítautomata Petri-hálóját, azt láthatjuk, hogy 
minden tranzíciónak egyetlen bemenő helye van, így biztosak 
lehetünk abban, hogy amennyiben a token ezen az ős-helyen 
van, a tranzíció mindenképp engedélyezett lesz, nem , ragad 
be" a működés. 

Másik lényeges szempont, hogy adott állapotból (tokenelosz- 
lásból) kiindulva elérhető-e minden hely, vagy vannak elszige- 
telt régiói a hálónak, amelyek semmilyen token-áramlással 
sem hozzáférhetőek. 

A mi Petri-hálónk összefüggő, így elszigetelt régiói nincsenek. 
Most már csak arról kell meggyőződnünk, hogy bármely he- 
lyén van is aktuálisan a token, onnan bármely másik helyre új- 
ra eljuthat. A háló e tulajdonságát élőségnek nevezzük. 
Amennyiben az egytokenes Petri-hálót egy irányított gráfnak 
fogunk fel, a probléma átfogalmazódik arra a kérdésre, hogy 
hány erősen összefüggő komponensből áll: ha egyből, akkor a 
háló élő, ha többől, akkor nem az. 

Egy irányított gráfról akkor mondjuk, hogy erősen összefüggő, 
ha bármely pontpárjára létezik olyan irányított út, amely az 
egyik pontból indul, és a másikban végződik (és fordítva). 
Olyan ez, mint ha egy képzeletbeli városban csupa egyirányú 
útjaink lennének, és autóval próbálnánk eljutni az A helyről B- 
be. Nyilván ez nehezebb probléma, mint gyalogosan, akikre 
nem vonatkoznak az egyirányúságra vonatkozó szabályok. 
Lássunk most egy módszert az erősen összefüggő komponen- 
sek meghatározására! Mélységi bejárással járjuk be az irányí- 
tott gráfot, s közben minden pontjához rendeljünk egy sorszá- 
mot. Ez a sorszám legyen az úgynevezett befejezési szám, 
amely azt mutatja, hogy az adott pontot hányadikként fejtettük 
ki teljesen (Egy pont akkor van teljesen kifejtve, ha már az 
összes gyerekét bejártuk). 

Készítsük el a gráf fordított gráfját, azaz fordítsuk meg minden 
él irányítását. Végül ezt a fordított gráfot járjuk be mélységi be- 
járással. Ha ez utóbbi bejárás során új gyökérpont választása 
nélkül be tudjuk járni a gráf összes pontját, a gráf egyetlen erős 
komponensből áll, azaz a Petri-hálónk (ahonnan kiindultunk), 
élő. 


A Petri-hálók még számos további tulajdonsággal jellemezhe- 
tők és analizálhatók, ezúttal ezekre nem térnék ki. Annyit je- 
gyeznék meg csupán, hogy a ma forgalomban lévő modellező 
eszközök széleskörűen támogatják a különféle analíziseket, így 
gyakorlatilag semmit nem kell manuálisan elvégeznünk, a há- 
ló konstrukciója után pillanatok alatt megkaphatjuk annak 
vizsgálatakor született eredményeket. 

Sok sikert, szerencsés próbálkozásokat kívánok mindenkinek! 


Molnár Ágnes 
agi€harpia.homeip.net 


Internet ExXlporer javítás 


Az Internet Exploreren két újabb biztonsági rést javíthatunk a 2003. február ele- 
jén megjelent MSO3-004-es számú hotfixszel. Mint már megszokhattuk, ez a ja- 
vítás tartalmazza az Explorerhez eddig kiadott javításokat, így ha valaki eddig 
elmulasztotta volna betömködni a már ismert réseket, az egyszerre megteheti az 
[Imsdownloadl] helyről letölthető biztonsági javítással. 
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A hibákat az Internet Explorer cross-domain biztonsági modell- 
jében találták, melynek a feladata az lenne, hogy a különböző 
domainekben megnyitott weboldalak ne oszthassanak meg in- 
formációkat. Azonban a hiányos biztonsági ellenőrzés követ- 
keztében az Internet Explorer lehetővé teheti, hogy egy párbe- 
szédablak használatával különböző domainben nyitott webol- 
dalak ugyanazokhoz az adatokhoz férjenek hozzá. 

Egy rosszindulatú támadó csak készít egy weboldalt, mely ép- 
pen erre a résre épít, majd a gyanútlan felhasználót megpróbál- 
ja rávenni, hogy az adott oldalt meglátogassa. Amint a felhasz- 
náló megnézi az oldalt, a támadó egy párbeszédablak segítsé- 
gével futtathat egy scriptet, melynek segítségével információk- 
hoz férhet hozzá. Megtudhatja melyek azok a rendszerfájlok, 
melyeket a felhasználó vagy az operációs rendszer nem hasz- 
nál, mi a fájlok neve és mi a teljes elérési útjuk. Hozzáférhet 
bármilyen adathoz, melyet más oldalakkal megosztottunk. A 
legrosszabb esetben akár azt is elérheti, hogy az adott scriptet 
ne csak futtassa, hanem el is helyezze azt a felhasználó rend- 
szerében. Ezen felül e résen keresztül a támadó futtatható állo- 
mányokhoz is hozzáférhet. 

Egy ezzel rokon rés lehetőséget ad arra, hogy az Internet Exp- 
lorer showHelp() függvényét a megfelelő biztonsági azonosítás 
nélkül futassuk. A showHelp() egyike azoknak a súgómetódu- 
soknak, mellyel HTML-oldalon jeleníthetjük meg egy súgófájl 
tartalmát. Ez a függvény több protokollhoz fér hozzá, mint 
amennyi szükséges, és ez potenciális lehetőséget nyújt egy 
támadónak, hogy felhasználói információkhoz férjen hozzá, 
futtatható állományokat hívjon meg, vagy rosszindulatú kódot 
töltsön egy felhasználó rendszerébe. 

Ebben az esetben is rá kell venni valakit, hogy látogasson meg 
egy adott oldalt az Interneten. Aztán a látogató gépén egy is- 
mert fájlt megnyit a támadó egy showHelp ablakban. Erről a 
fájlról az összes elérhető információt elküldi egy második 
showHelp ablaknak egy ravasz URL-en keresztül, így szerezve 
meg adatokat. 

A biztonsági hiba folytán a támadó hozzájuthat egy oldal által 
tárolt cookie-hoz, a felhasználó gépén található fájlok tartal- 
mát is megismerheti, sőt a HTML Helpek által támogatott short- 
cut függvénnyel akár paraméterezett utasításokat is futtathat. 
Így ha böngészés közben hirtelen elindul az aknakereső, való- 
színűleg támadás áldozatai lettünk, és itt az ideje a biztonsági 
rendszerünkön tátongó lyukakat befoltozni. 

Az alábbi példa mutatja, milyen könnyen hozzáférhetünk akár 
egy cookie tartalmához is: 


cscript5 

showHelp("file:"); 

showHelp ( "http: //www.netacademia.net" 
showHelp( "javascript : alert (document . 
4/script: 





Eredményül egy sütit, és egy Help-ablakba szorított weblapot 
kapunk: 


Microsoft Internet Explorer 


! y ASPSESSIONIDOOGOOBNK-CIDMFOADDMIGIKILDCCNNKIE 


ASP munkamenet sütije 





Ha ezt a javítást telepítjük, a window.showHelp() függvény el- 
érhetetlenné válik. Telepítsük a legutolsó HTML Help Update-t, 
és a showHelp() újra meghívható, működik. Hozzá kell azon- 
ban tenni, hogy ekkor már bizonyos korlátozások lépnek élet- 
be a függvény használatakor. 


A A showHelp csak a támogatott protokollokat használ- 
hatja, amikor egy weboldalt vagy egy súgófájlt (.chm) 
nyit meg. 

HA A HTML Help támogatja a shortcut függvényt, mellyel 
különböző utasításokat készíthetünk Például, ha egy 
HTML Helpben egy adott szóra kattintunk, akkor elin- 
dítja a NotePadot, vagy éppen nyit egy új információs 
ablakot. Ez a lehetőség a javítás telepítése után már 
nem működik, ha a súgót a showHelp0 függvénnyel 
hívtuk meg. Ha a felhasználó dupla kattintással nyitja 
meg ugyanezt a fájlt, a shortcut újra használható. Akkor 
sincs megkötés, ha egy alkalmazás súgóját használjuk. 


Végül nézzük, az Internet Explorer mely verzióihoz adták köz- 
re ezt a javítást: 


Internet Explorer verzió Platform 


IE 5.01 S$P3 Windows 2000 SP3 
IE 5.5 S$P2 Windows Milennium 
IE 6.0 Gold Windows XP Gold 
IE 6.1 SP1 Windows XP SPT, 


Windows 2000 $P3, 
Windows NT 4.0 sp6a, 
Windows Millenium, 
Windows 98. 


A telepítés után a gépet újra kell indítani. A javítást ezek után 
eltávolítani nem lehet! 


Borsi Katalin 
bobocnetacademia.net 
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A bitlegelők tragédiája 


Egyszer volt, hol nem volt, volt egyszer sok tehénpásztor. Az egyik arra gondolt, 
hogy több tehén többet tejel, ezért megnövelte a csordája létszámát. Kiderült, hogy 


igaza lett, mire a szomszéd pásztor is hasonlóképp tett. Egy bolond százat csinál, 
de még a felénél sem tartottak, amikor annyi tehén bőgött a réteken, hogy már 


egyikük sem lakott jól teljesen... 


Emiatt persze kevesebb tejet adtak, így akik még tovább bőví- 
tették a csordájukat, csak a többiek rovására tudtak javítani az 
eredményükön. Végül annyi jószág legelészett, hogy már az is 
rosszul járt, aki magának vásárolt tehenet. Ez az együttműkö- 
désre képtelen, oktalan pásztorok egyensúlyi helyzete. 

E problémát elsőként Garrett Hardin biológus vázolta fel 1968- 
ban [population]. Az elmélet oly frappánsan írja le az embe- 
reknek a közjavakkal szemben tanúsított viselkedését, hogy 
más tudományágak is sikerrel alkalmazták, és alkalmazzák a 
mai napig. Az Internet például nagyon hasonlít egy közlegelő- 
re, amelyen kódpásztorok milliói legeltetik programjaikat. A 
sávszélesség gátlástalan bitorlásának következményével, a tor- 
lódással, ilyen vagy olyan formában már bizonyára mindenki 
találkozott. A torlódásvédelem egyidős az Internettel, és a ka- 
pacitásnál gyorsabb ütemben növekvő felhasználás miatt (amit 
gúnyosan nevezhetnénk akár multimédiás őrületnek is) egyre 
inkább a figyelem középpontjába kerül. 

Az Internet protokolljai pillanatnyilag nem dúskálnak a torló- 
dásvédelmi lehetőségekben. A TCP időtúllépésével, illetve cso- 
magvesztésével gyakorlatilag ki is merítettük a sort. Dehát ak- 
kor mit lehet tenni? Ezegyszer végre — a megszokott iránytól el- 
térően — a közgazdaságtudomány siethet a műszaki élet segít- 
ségére. A kereslet-kínálat kézenfekvő következménye, hogy az 
erőforrások felhasználása szabályozható az ár változtatásával. 
Ez a trükk köszön vissza például a telefondíjak időzónásításá- 
nál, az olcsóbb éjszakai áramnál, vagy egyes országok autópá- 
lyadíjainál. Ilyenkor a terhelés kiegyenlítése a cél, mivel mű- 
szaki-gazdasági szempontból általában ez a legkedvezőbb. Az 
Internet vagy egy Intranet sem különb. Nem keveredtünk itt el- 
lentmondásba? Ha szigorúak akarunk lenni, a válasz igen. A 
problémafelvetés ugyanis a közjavakkal kapcsolatban történt, 
ha viszont valaminek árat szabunk, akkor az elveszti "köz" jel- 
legét. Csakhogy a költséget az internetező nem biztos, hogy 
közvetlenül díj fizetésével viselné, elképzelhető mindez a ren- 
delkezésére bocsátott sávszélesség nagyságának korlátozásá- 
val. A kevésbé kötekedő felelet tehát lehet nem is. 

Lássuk egy egyszerű példán, mit jelent mindez? Egy vállalatnál 
előnyben részesíthetjük a videokonferenciákat és az igazgató 
webezését a többi alkalmazással és felhasználóval szemben, 
ami abban nyilvánul meg, hogy ezek a beállításoktól függő 
mértékben nagyobb sávszélességet kapnak. Ha azonban a ki- 
emelt alkalmazások egyike sem fut, a felszabadult sávszélessé- 
get a többi alkalmazás minden további nélkül használhatja. 
Ugyanez az elv egyetlen számítógép és felhasználó esetében is 
alkalmazható, például úgy, hogy az elektronikus levelek küldé- 
sének nagyobb prioritást adunk, mint a webezésnek vagy az 
FTP letöltéseknek. 


A Resource Pricing modell bevezetése az Interneten már a 90- 
es évek eleje óta napirenden van, és a Microsoft Research há- 
lózati csoportja is próbálkozik ennek megvalósításával [cowsl]. 
Peter Key kidolgozott egy olyan modellt, amelyben a túlterhe- 
lődő erőforrások (processzor, memória, tápegység, sávszéles- 
ség stb.) ára emelkedik, és így elvben akár az egész Internetre 
alkalmazható lenne. Az alapötlet szerint torlódás kialakulásá- 
nál az útválasztók megjelölik a csomagokat. Ezek a jelek lehet- 
nek nagyon egyszerűek, mint például az IETF Explicit Conges- 
tion Notification (ECN) ajánlásában (RFC 3168), ahol mind- 
össze egyetlen bit jelzi a forgalmi dugó kialakulását, de lehet- 
nek ennél sokkal kifinomultabbak és értelemszerűen bonyolul- 
tabbak is. Okosan megválasztott költségfüggvénnyel befolyá- 
solható a sávszélesség felhasználása. Ha a költség pénz formá- 
jában nyilvánul meg, magától értetődő, hogy a felhasználókat 
mi ösztönzi a játékszabályok betartására. Ha mégsem, akkor 
elképzelhetők például olyan alkalmazások, amelyek korláto- 
zott mennyiségű jelet használhatnak fel adott idő alatt, és pró- 
bálnak abból jobban gazdálkodni, mint mi a havi fizetésünk- 
ből. A torlódásjelzés információtartalmának nagysága vitatott 
téma. Az ECN megkérdőjelezhetetlen előnye, hogy az IPv4 fej- 
léc Type of Service mezőjének két kihasználatlan bitjét hasz- 
nálja fel. Ez azonban meglehetősen kevés például a torlódás 
mértékének vagy helyének a jelzésére. Több bites leírásra al- 
kalmas lesz az IPv6, de ha addig nem bírjuk cérnával, az ope- 
rációs rendszerekbe építhető torlódáskezelő is megoldás lehet. 
Nemsokára valószínűleg a Windowsokban is találkozhatunk 
vele. 

A modell bevezetése az Interneten azonban egy komoly társa- 
dalmi kérdést vet fel: mi alapján állítunk fel sorrendet az em- 
berek között? Richard Black sem tett kísérletet a válaszra, he- 
lyette a vállalati és otthoni hálózatokra készített prototípussal 
tesztelte Key modelljének használhatóságát, pozitív ered- 
ménnyel. A sikereken felbuzdulva Key és Dinan Gunawardena 
néhány népszerű hálózati alkalmazáson, többek között a Win- 
dows Median és a Windows Messengeren is kipróbálta az öt- 
letet. Működött. A kép- és hangminőség például a hálózat ter- 
heltségének függvényében változott, biztosítva ezzel az adás 
folyamatosságát. 

Hardin mély meggyőződéssel vallja, hogy a közlegelő típusú 
problémáknak nincs technikai értelemben vett megoldása, ez 
csak és kizárólag az erkölcsi normák megváltoztatásával lehet- 
séges [population]. 


ZaccoGgfw.hu 





Magyarországon ma féltucat helyen tanítanak hivatalos 
Microsoft-tananyagból (MOC),. 


A tankönyv mindenütt ugyanaz. 
Minden más - nálunk más! 


A legfelkészültebb oktatók (a tech.net magazin szerzői) 

A legtöbb információ (sok-sok plusz anyag, előadások és magyar nyelvű háttéranyagok) 
A legjobb időbeosztásban (NetAcademia módszerrel) 

A legszebb környezetben (Andrássy Palota) 


A NetAcademia módszer (NATE) 
Heti fél nap, nyolc héten át - feszes tempó, lélegzetvételnél nagyobb (1 hetes) szünetekkel. 
Előnyök: 

J Könnyebb elsajátítani a tanulnivalót 

J Egy hetes tanulási, ismétlési intervallum 

J A résztvevő nem esik ki a munkából 

J  Vidékiek is könnyedén elvégezhetik 


(EGEK EZ GUNN (KN (GN GMEN KN KN BENN 
a jaja ig 















Részletes tematika és jelentkezés: http ://www.netacademia.net 
Kérje teljeskörű, ingyenes katalógusunkat az info(;pDNetacademia.net címen! 









A vállalatok életében a siker sokszor a napi irodai 


munka hatékonyságán múlik. A MonDoc egy 
olyan moduláris, Exchange Server alapú keret- 
rendszer , amely a legkorszerűbb dokumentum- 


és egyéb 









; Gz jú kezelési, tudásmenedzsment-, workflow- 
Precíz dokumentumkezelés, célzott folyamatok irodazútoratk legyek 


szokott /Outlook/ felhasználói környezetben. 








si megoldá a meg- 


A MonDoc a dokumentumok létrehozását továb- 





bítását, mentését támogató integrált irodai 
munkatámogató (csoportmunka) rendszer. 





Működtetésével valamennyi napi tevékeny 
gondosan tervezhetővé, precízen követhetővé, 






egyszerűen hozzáférhetővé, jól 





álik. A rendszer biztosítja az ISO 
9001 szabványok: 


informatikai hátteret, valamint a digi- 





ak megfelelő működéshez 





tális aláírás használatát. 


Célozza meg a legbatékonyabb 
megoldást vállalatának! 


Ci MON 


1085 Budapest, 

Gyulai Pál u.13. MONA 

Tel.: (1) 327-9800 Montana in ológiai és Kommunikációs At. 

Fax: (1) 327-9801 24 tő 

elonyomontana.hu . Előny a felhasználónál 


www.montana.hu 














tech.net magazin 
előfizetési szelvény 


Címzett: NetAcademia KÉt. 
Faxszám: (1) 472-1215 





IK] 


http://technet.netacademia.net/subs/szamrend.asp e e-mail: terjesztesonetacademia. net e fax: (1) 472-1215 


Előfizetem a tech.net magazint: 
áá öleáts példányban egy évre (14.784 Fb) 
Máté ágés példányban fél évre (7.392 FW. 


A fizetés módja: LI csekkel LI átutalással 
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MesterOrzus megrendelőlap 


Címzett: NetAcademia Kft. aX 


Faxszám: (1) 472-1215 





A 2003 első félévében megrendezésre kerülő MesterOrzus konferenciák: 


2003. március 27. 13:45 - 18:00 5000 Ft--ÁFA/fő 
Fóti Marcell: Bevezetés a hálózati forgalom elemzésébe 
NetLock Kft. vendégelőadó: A nyílt kulcsú technológia építőkockái 
Fülöp Miklós: Nyílt kulcsú architektúra a Windowsban 


Gyakorlat: Felhasználói és kiszolgálóoldali PKI-gyakorlatok 


Ajándék: Hiteles NetLock tanúsítványpár elektronikus aláíráshoz és titkosításhoz. A kulcstároló eszközök a helyszínen 
megvásárolhatók. 


2003. május 29. 13:45 - 18:00 5000 Ft--ÁFA/fő 
Fóti Marcell: Az elektronikus levelezés védelmének lehetőségei Exchange Serveren 
Soczó Zsolt: SOAP 


VirusBuster Kft. vendégelőadó: A Windows rendszerek támadható, és védelmi felületei 
Gyakorlat: Felhasználói és kiszolgálóoldali PKI-gyakorlatok 
Ajándék: Virus Buster Personal Edition, 1 éves előfizetéssel 


A konferenciákkal kapcsolatban a változtatás jogát fenntartjuk! 





Megrendelem a MesterOrzus konferenciákon való részvételt az alábbiak szerint: 


2003. március 27. — ............... fő 

2003. május 29. — ............... fő 
Megrendelő nevé (kapcsolatáról s sezeáeszüte esz sára pagya AE SANS EST AKT ÉLEN EEG YEBÉS 
CSE NEVÉ LES néz ÉL RNS ÁSÁS LEBEN EKB NAL EÁT S SÁS KKT OEK 


Bővebb információt a http://www.netacademia.net/mesterg honlapon talál, illetve a következő elérhetőségeinken kérhet: 
Tel.: 472-1214 Fax: 472-1215 info.-donetacademia.net 





Ha úgy érzi, a hálózatok csapdájába esett és a helyzet reménytelen, 
jöjjön el a SZÁMALK Továbbképzés Cisco tanfolyamaira, 
ahol megtalálhatja a megoldást... 


A SZÁMALK Továbbképzés saját fejlesztésű és tematikájú, hivatalos Cisco anyagokra épülő 
tanfolyamokat indít, elsősorban a hálózati valamint hang- és adatátviteli technológiák területen. 


A magas szintű hálózati ismeretek nélkülözhetetlenek az összetett informatikai rendszerek 
üzemeltetéséhez és hivatalos Microsoft képzéseink hatékony elsajátításához is. 


Kedvező ár, korszerű hardver- és szoftverkörnyezet, egyedileg összeállított hallgatói jegyzet, 
eredeti segédanyagok, minősítő vizsgával rendelkező oktató. 


Tavaszra meghirdetett tanfolyamaink: 
Cisco kapcsolt hálózatok: április 7-11. R 
Cisco hálózati alapismeretek és eszközök: április 14-18. 
Cisco skálázható hálózatok kiépítése, tervezése: május 19-23. 


A tanfolyamokkal kapcsolatos további információkért, teljes kínálatért kérjük keresse munkatársainkat, 


látogassa meg internetoldalunkat! Figyelje tanfolyamokhoz kapcsolódó akcióinkat is! vaty 
; 7/afttgg 











ni 


Legyen Ön is hivatalos szakértő! Tanfolyamaink a hivatalos vizsgákra való felkészülésben is 
segítenek. Nemzetközi minősítést szerezhet, akár egy vizsgával is! 





Egészítse ki tanfolyamain § 
hivatalos szakkönyvekkel! ez 


A SZÁMALK Továbbképzés a NerOSoTt é és Gisa ! 
S eKESNKOS zée. tanapyasol és S 


a 203-0304/3050 (Simon Ferenc) www.szamalk.hu/jtisza 1115 Budapest, Etele út 68. 


